SQL glued together from user input
When your code builds SQL by sticking user input into a string, a stranger can rewrite the query. AI scaffolds do this far more often than hand-written apps.
What can go wrong
SQL injection means an attacker edits the query your database runs by typing special characters into a search box, URL parameter, or form field.
Common AI patterns: joining strings to form a WHERE clause from request parameters, embedding variables inside backtick SQL strings, and using ORM "unsafe raw query" helpers that accept interpolated text instead of bound parameters.
Safe escape hatches exist (tagged template helpers and parameterized queries), but models often reach for the unsafe shortcut because it compiles on the first try.
It happened for real
In February 2026, OopsSec documented a live analytics tracker that interpolated user-controlled values into an unsafe Prisma raw query (OopsSec, Feb 2026). Prisma maintainers confirm unsafe raw queries with embedded variables are injection; use the tagged safe helper instead (Prisma Discussion #26013).
VibeDoctor reported AI-generated code uses unsafe SQL patterns at roughly 2.74× the human rate. vibe-eval found similar issues in about 30% of the apps it sampled.
How to check yours
Seatbelt flags this automatically. String-built SQL, unsafe raw query calls, and template-interpolated SQL in your repo are must-fix hard gates.
Ask your agent: "Find every unsafe raw SQL call and string-built query in the repo. Replace each with parameterized queries or the ORM's safe tagged template."
We don't catch this yet: SQL built entirely in the hosting dashboard or an external BI tool with no source in the repo you export.
Fix direction
Never interpolate user input into SQL strings. Use ORM query builders, safe tagged templates, or bound parameters.
Paste into your agent: "Replace all unsafe raw SQL and string-concat queries with parameterized queries. Show before and after for each route."