LangChain SQLDatabaseChain: Prompt-to-SQL Injection
On this page
Ask in English, run in SQL — with the model's query executed verbatim against your database.
| When | July 2023 |
|---|---|
| Target | LangChain SQLDatabaseChain |
| Vendor | LangChain |
| Technique | Unvalidated LLM-generated SQL executed live |
| CVE | CVE-2023-36189 — CVSS 3.1 7.5 (High, NVD) |
- 1SQLDatabaseChain turns a natural-language question into SQL via the LLM
- 2It executes that SQL directly against the database, unvalidated
- 3A crafted question steers the model into emitting malicious SQL
What happened
LangChain's SQLDatabaseChain turned a question into SQL via the LLM and then executed that query directly against the database with no validation or parameterisation. A crafted question could steer the model to emit SQL that reads or alters unauthorised data, which the chain ran verbatim — CVE-2023-36189. The component was later moved to langchain-experimental due to this class of risk.
How it worked
The malicious SQL originates in the model's output, so input-layer defences don't see it. The unvalidated, executed LLM-generated query is the injection.
Root cause
Executing model-generated SQL against a live database with no validation, parameterisation, or privilege limits.
What a test would have caught
Prompt-to-SQL injection testing — asking questions designed to produce destructive or out-of-scope SQL and checking what runs — surfaces this class.
How to prevent it
- Don't execute LLM-generated SQL unvalidated; constrain and review it.
- Use least-privilege, read-only DB accounts for query features.
- Treat generated queries as untrusted input to the database.
Feel it yourselfThe replay lab turns a model's generated query into a database injection — the improper-output-handling class.
FAQ
How is this different from classic SQL injection?
The malicious SQL originates in the model's output, not the raw user input — so input-layer defences miss it. The unvalidated LLM-generated query is the injection.
What could it do?
Steer the model to emit SQL that reads or modifies data it shouldn't — the query was run verbatim against the live database.
What's the fix?
Never execute LLM-generated SQL unvalidated; use parameterisation, least-privilege DB accounts, and treat generated queries as untrusted (the component was moved out of core for this risk).
Sources
- langchain SQL Injection vulnerability (GHSA-7q94-qpjr-xpgm / CVE-2023-36189) — GitHub Advisory Database
- From Prompt Injections to SQL Injection Attacks — Pedro et al. (arXiv)
- SQL Injection in langchain, CVE-2023-36189 — Snyk