SQL Injection Stacked DML Privilege Abuse
An AI agent that builds SQL queries from user input (like sort or filter fields) can be tricked into running a second, hidden database command. Instead of destroying data, the attacker quietly edits it — for example, marking an unpaid order as paid, creating a hidden admin account, or granting themselves database permissions.
How the attack works
The attacker finds an agent input, such as an order or filter parameter, that gets passed into a SQL query without proper sanitization. They end the legitimate query early with a semicolon and append a second statement — UPDATE, INSERT, or GRANT. The database executes both statements as one batch, since it has no way to tell the injected command was not intended. The result is a silent change: altered records, a new unauthorized user, or expanded privileges, with no crash or error to alert anyone.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- cc57d029-ac62-425f-a6b8-5827db486c95
- Severity
- Critical
Why it matters
An organization can end up with tampered business data (like bypassed payment checks), unauthorized accounts with admin access, or attackers who have escalated their own database privileges — all without any visible outage or obvious error.
What you can do
- →Use parameterized queries or prepared statements for all inputs that reach SQL, especially fields used for sorting or filtering.
- →Disable support for stacked/batched SQL statements in the database driver or connection settings where not needed.
- →Apply least-privilege database accounts to agents so they cannot run UPDATE, INSERT, or GRANT statements outside their intended scope.
- →Review database audit logs for unexpected DML or GRANT statements following user-facing query execution.
Known benign look-alikes
- Database migration scripts run by authorized migration agents
- Administrative database management with explicit grant permissions