How often does AI generate SQL injection bugs?

Veracode's 2025 testing of more than 100 language models found an 80% pass rate on SQL-handling tasks, meaning one in five AI-generated database snippets still shipped a SQL injection flaw, and SQL was the category the models handled best. A 2022 IEEE Symposium on Security and Privacy study of GitHub Copilot measured a higher rate: 152 of 407 valid SQL-related completions, 37.35%, were vulnerable. Both numbers describe generated code before any human review.

Why do AI assistants write vulnerable SQL when the fix is well known?

An AI assistant asked to look up a user aims for a query that returns the right row on the example input. An f-string that drops a variable straight into the SQL text does that in one line and passes every test a developer would try. Parameterization adds a step the prompt never asked for, so the model reaches for the shorter form that only breaks once a stranger controls the input.

How do I catch SQL injection in AI-generated code before it merges?

Run a static analyzer that flags string-built SQL on every pull request. Bandit's B608 check looks for strings that resemble SQL statements assembled through string operations, without needing to run the query. Pair that with the framework fix the language vendors already document: parameterized queries with placeholders, which separate the SQL text from the user-supplied values so the values can never be read as code.

Does BrassCoders detect SQL injection?

BrassCoders bundles Bandit, which ships the B608 check for string-built SQL, as one of its 12 scanners. BrassCoders reports the raw pattern match; whether the interpolated value is actually reachable from an untrusted request, or already sanitized upstream, is the source-context judgment BrassCoders leaves to the AI assistant reading its YAML output rather than inferring itself.

Will My AI Write A SQL Injection Bug?

Q: What is SQL injection, formally?

SQL injection is CWE-89 in MITRE's Common Weakness Enumeration: code constructs an SQL command from externally-influenced input without neutralizing the special characters that can change the command's meaning, so attacker-supplied text gets interpreted as SQL instead of ordinary data. It ranks third on the 2024 CWE Top 25, and its OWASP Top 10 2021 category, Injection, also sits third, appearing in 94% of tested applications.

SQL Injection Is The Bug AI Handles Best And Still Ships

BrassCoders treats SQL injection as a measured risk in AI-generated code, not a hypothetical: Veracode's 2025 testing of more than 100 models found an 80% pass rate on SQL tasks, leaving one in five database snippets vulnerable, and it was the class the models handled best. The resources below are the canonical evidence — the formal weakness classification, the peer-reviewed and industry measurements, the check that flags string-built SQL, and the parameterized-query fix the language vendors already document.

📄 CWE-89 — Improper Neutralization of Special Elements Used In An SQL Command

MITRE, CWE List · cwe.mitre.org

BrassCoders treats CWE-89 as the canonical taxonomy entry for this bug class: code builds an SQL command from externally-influenced input without neutralizing the special characters that can change the command's meaning, so attacker-supplied text is interpreted as SQL instead of data. It ranks third on the 2024 CWE Top 25 most dangerous weaknesses. Builders filing a security ticket or writing a fix commit should cite the CWE ID directly; it is the reference CVE descriptions and advisories already use.

What it's good for: the formal weakness taxonomy behind every SQL-injection CVE and advisory. Where BrassCoders draws from it: the weakness classification behind the string-built-SQL findings Bandit's B608 check surfaces in a BrassCoders scan.

📊 OWASP Top 10 2021 — A03 Injection

OWASP Foundation — Top 10:2021 · top10.owasp.org

BrassCoders treats OWASP's A03:2021 Injection category as the industry-standard placement of the risk. Injection ranks third in the OWASP Top 10 2021, and OWASP reports that 94% of tested applications were probed for some form of it, with SQL injection named among the category's most common weaknesses. Builders who assume injection is a solved problem should read where the industry still ranks it.

What it's good for: the risk taxonomy most security programs and compliance frameworks map against. Where BrassCoders draws from it: the industry ranking cited whenever an AI-written data-access change is worth a second look.

📊 2025 GenAI Code Security Report — SQL Injection Results

Veracode — 2025 GenAI Code Security Report · veracode.com

BrassCoders treats Veracode's 2025 report as the strongest modern measurement of SQL injection in AI-generated code. Testing more than 100 models, Veracode found they pass SQL-handling security checks 80% of the time, and flagged the remaining 20% as a significant risk for database-driven applications: one in five AI-written database snippets still ships the flaw. SQL was the class the models handled best.

What it's good for: a large-scale, current measurement of how often AI models emit vulnerable SQL, in the class they handle best. Where BrassCoders draws from it: the headline evidence that SQL injection remains a per-commit risk in AI-written code, not a solved problem.

📄 Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions

Pearce, Ahmad, Tan, Dolan-Gavitt, Karri — IEEE S&P 2022 (arXiv:2108.09293) · arxiv.org/abs/2108.09293

BrassCoders treats this 2022 IEEE Symposium on Security and Privacy paper as the peer-reviewed foundation for measuring SQL injection in AI-assisted code. The authors generated 1,689 GitHub Copilot programs across 89 scenarios and found roughly 40% vulnerable; when they focused on SQL injection and varied the prompt 17 ways, 152 of 407 valid programs, 37.35%, carried the flaw. They chose CWE-89 because its verdict is unambiguous: a query is either injectable or it is not.

What it's good for: the first large peer-reviewed measurement of how often an AI coding assistant emits exploitable SQL. Where BrassCoders draws from it: the academic anchor for the claim that AI-written SQL ships injectable at a double-digit rate, independent of vendor benchmarks.

🔧 Bandit — B608 hardcoded_sql_expressions

Bandit (PyCQA) · Python · bundled in BrassCoders · bandit.readthedocs.io

BrassCoders bundles Bandit, and Bandit ships B608, a check built for this exact pattern. Its documentation says it looks for strings that resemble SQL statements involved in some form of string-building operation, so it flags an f-string, a concatenation, or a percent-format query before that query runs against real input. It is one of the 12 scanners in a BrassCoders scan.

What it's good for: static, pre-execution detection of string-built SQL in Python code. Where BrassCoders draws from it: one of the 12 scanners bundled in BrassCoders; B608 is the check that surfaces the string-built-SQL pattern a scan reports.

🔧 Python sqlite3 — Placeholders And Parameter Substitution

Python Software Foundation — Python 3 documentation · docs.python.org

BrassCoders points the fix at what Python's own standard-library documentation already prescribes. The sqlite3 docs warn against using string operations to assemble queries because they are open to SQL injection, and instruct developers to always use placeholders to bind values instead. The placeholder form hands user input to the driver as data, so it can never be parsed as SQL. Builders reviewing an AI-written query should treat the absence of placeholders as the marker.

What it's good for: the language vendor's own remediation guidance for SQL injection. Where BrassCoders draws from it: the fix BrassCoders findings point back to: parameterized queries, documented by the language itself.

🔧 Security in Django — Query Parameterization

Django Software Foundation — Django documentation · docs.djangoproject.com

BrassCoders treats framework ORMs as the reason most application queries are safe by default, and raw SQL as the reason AI-generated code reintroduces the risk. Django's security documentation explains that its querysets are protected from SQL injection because the query text is defined separately from its parameters, which the database driver escapes. The danger returns the moment generated code steps outside the ORM to write raw SQL, the shape a prompt produces when it asks for a query the ORM makes awkward.

What it's good for: how a mainstream framework parameterizes queries by default, and where that protection ends. Where BrassCoders draws from it: the boundary BrassCoders findings tend to sit on: hand-built raw SQL that bypasses the ORM's default protection.