Oops! A SQL injection bug just forced an emergency WordPress core patch last week.
On July 17, WordPress shipped an emergency release to fix an unauthenticated remote code execution flaw in the core, reachable via a SQL injection that an anonymous attacker can exploit on a stock install. WordPress.org even turned on forced auto-updates because of how severe it is. Searchlight Cyber, who reported it, estimates over 500 million sites run WordPress. If you’re affected, move to Version 7.0.2, and 6.9.5 for the older branch.
SQL injection, also stylized as SQLi, is an old vulnerability with an easy fix, so people assume it’s dead. But as we were just reminded, it’s not.
SQL injection: From humble beginnings to modern day
SQL injection and its solutions are part of Computer Science 101 classes. I remember learning about prompt injection in university over a decade ago, and honestly, it’s the only application-based vulnerability I remember them teaching (I think they moved on to other topics after covering it, or maybe I didn’t pay attention after that).
SQL injection was written up publicly in 1998 by the researcher known as rainforest puppy. The fix that solves most SQLi issues, prepared statements, was figured out about a year later. The fix is older than many engineers at the company. Use parameterized queries and keep user input as data. But even with a fix around, SQL injections still happen.
Based on the data from the GitHub Advisory Database, filtering advisories by CWE and counting per year:
The count of SQL injection advisories rose every full year from 2023 to 2025, from 2,096 to 2,850. The three oldest injection classes together, SQL injection, command injection, and path traversal, still make up more than one in ten of everything reported.
OWASP moved injection from third to fifth in its 2025 Top 10, but not because things are fixed. The overall injection category still carries more reported CVEs than any other, with more than 60,000 reported. Of that, SQL injection alone had over 14,000. In Mackenzie's scans of closed-source repos, 20% of projects had at least one SQL injection flaw on their first scan.
Why SQL injection refuses to die
First, to get it out of the way, people make mistakes when writing code. It happens. So every once in a while, a SQLi is going to slip through. But the modern systems that should help us don’t do so one hundred percent of the time, and can even cause us to make different mistakes.
For example, newer frameworks have methods to help prevent SQL injection. ORMs like Django, Hibernate, and ActiveRecord parameterize by default, which convinces a lot of teams the problem is handled. But if someone drops to a raw query or hits an unsafe method, the protection is gone.
Django's CVE-2024-42005 is an example. Two of Django's own query methods, used to read fields out of a JSON column, dropped the field names you passed straight into the SQL without cleaning them, so an attacker who controlled a name could control part of the query, through a method teams assumed was safe.
On the flip side, really old code is also a problem, with legacy code carrying these flaws forward for decades. Teams lean on a WAF and assume (pray) it catches everything. While the fix has existed for over 25 years, applying it across every query, every endpoint, and every legacy corner, every time, is a whole lot of tedious work that hasn’t been completed in full across every codebase ever. The way Mackenzie Jackson, our field CTO, frames it, this stopped being a technical problem and became a culture, process, and education one.
And of course, AI.
AI writes SLQi too
The obvious hope is that AI coding assistants, trained on decades of examples, would stop reproducing a 1998 bug. But as we know, AI does not write perfect code.
We can look at this quantitatively. The 2021 Asleep at the Keyboard study from NYU and Cornell generated 1,689 programs from GitHub Copilot across common weakness scenarios and found about 40% were vulnerable, with SQL injection and command injection among the most frequent. Mackenzie's own test lands in the same range. Running one prompt through ChatGPT a few hundred times, about 12% of the results were injectable, close to the rate across open source.
But why? Models learn from public code that carries these flaws, so they reproduce them at a similar frequency. AI handles SQL injection better than it handles context-heavy bugs like cross-site scripting, where the same report found most output insecure. AI continues to improve, so these figures will be out of date in six months, but we can expect AI will still write this accidentally, just as we do.
And now, more vibe-coders and less technically trained people are writing code. They’re less likely to recognize SQL injections (if they even know to look for them), so more code can enter the company codebase without trained eyes looking to make sure this issue is accounted for.
Which is why you gotta have a backstop
Even if you do everything right, like parameterized queries everywhere, allowlists on every input, what have you… You still want runtime protection. Perfect sanitization across every endpoint, forever, is not a thing. SQLi might even happen in a vulnerable dependency you don't control (or say, a website host’s default site), which is beyond anything you can reasonably manage.
Aikido Zen is an in-app firewall that runs inside your application and watches user input as it moves toward a data sink, like a database query or file read.
When an attack payload is about to reach one of these places, Zen blocks it in the moment, with enough app context to tell an attack apart from a search string that happens to look like one.
It also covers flaws that arrive through dependencies, where your own coding standards don't reach. Treat it as a runtime backstop for when secure coding falls short, which in practice it always does. Zen is RASP, which understands dangerous inputs at a code level. This is different from a WAF that blocks suspicious input at the network level, which is less precise, so it has a tendency to block too much. I go into this in much more detail in our post on WAF vs RASP vs ADR.
An in-app firewall like Zen stands between wp2shell and an unpatched WordPress site. Zen is built to block the SQL injection this flaw relies on, so a site waiting on the update still had a defense while the patch rolled out.
Catch SQL injections in your dev branch
Runtime is the safety net, but prevention is of course the gold standard. Ideally, we find and remove all SQL injection in the code.
Static analysis like SAST catches a lot of SQL injection, the plain kind where input runs into a query with no parameterized statement. It would not have caught this one. WordPress core is about as scanned as software gets, and this bug wasn’t caught. In this case, the injection only becomes exploitable when a malformed batch request knocks WordPress's internal bookkeeping out of alignment, so the value reaches the database through a path that skips the cleanup. That's a cross-request interaction a static scanner isn’t able to walk through. Finding this vulnerability took a frontier model running four agents for six hours.
The everyday injection is your scanner's job. The buried, logic-dependent kind increasingly takes an AI to go find it before someone else does, which is the case for Aikido AI pentesting and pointing it at your own code the way this researcher pointed one at WordPress. Aikido has continuous pentesting with Aikido Infinite, which can help you regularly check for any new SQLi that may try to make its way through code review.
Little Bobby Tables is still alive and healthy. Take him seriously, and secure your code, even the boring stuff.
