# AI turned a routine SQL bug into a WordPress catastrophe > Source: > Published: 2026-07-20 12:08:34+00:00 [Security](https://sourcefeed.dev/c/security)Article # AI turned a routine SQL bug into a WordPress catastrophe The scary part of wp2shell isn't discovery. It's how cheaply a model chained the flaw to full RCE. [Ji-ho Choi](https://sourcefeed.dev/u/jiho_choi) The number in the headline is the part you should trust the least. Adam Kues of [Searchlight Cyber](https://slcyber.io) says he spent about $25 of model time and walked away with a pre-auth remote code execution chain against stock [WordPress](https://wordpress.org) — the kind of bug exploit brokers supposedly pay half a million dollars for. The $500k figure is a market rumor he never tested; he didn't try to sell it, and his employer sells AI-assisted security tooling, so read the price tag as marketing. The bug is real, though. It's now tracked as CVE-2026-60137 and CVE-2026-63030, collectively **wp2shell**, and it's being exploited in the wild as you read this. The interesting story isn't the economics of the sale. It's the economics of the *labor*. ## The bug is boring. The chain is not. Strip away the AI framing and the underlying flaw is almost embarrassing: a string-concatenation SQL injection in `WP_Query` , reachable through the `author__not_in` parameter on the REST posts endpoint. In 2026. In the CMS that runs [over 500 million sites](https://www.bleepingcomputer.com/news/security/wordpress-core-wp2shell-rce-flaws-get-public-exploits-patch-now/). That's the sort of finding a decent static analyzer or a bored human should have caught years ago, and plenty of people on Hacker News said exactly that. But SQL injection alone doesn't get you a shell. WordPress hardened its query layer for a reason, and a read-oriented injection in a `SELECT` is a long way from executing code. The reason wp2shell matters is the second CVE — CVE-2026-63030, a batch-route confusion in the REST API. WordPress shipped a Batch API back in 5.6 (2020) that lets a client bundle many virtual requests into one call. Kues's chain abuses a desync between how that endpoint *validates* requests and how it *executes* them, then stacks the SQL injection on top to forge post rows, poison the oEmbed cache, and smuggle a malicious `customize_changeset` into the pipeline. The finale replays a batch request through the `parse_request` hook with administrator privileges, creates an admin account, and uploads a plugin. Game over. That escalation — from a single injected `SELECT` to full RCE across four unrelated WordPress subsystems — is the actual work. And that's the work the model did. ## What the model actually replaced Here's the honest split. Finding the injection point is something modern tooling already does; grep, taint analysis, and a patient junior researcher all get there. What almost never happens is a human sitting down and, in an afternoon, threading a five-gadget privilege-escalation chain through the cache layer, the changeset system, the embed handler, and the request router. That's not clever. It's *exhaustive*. It's the kind of combinatorial spelunking humans give up on around hour three because the payoff is uncertain and the state space is enormous. Kues pointed OpenAI's [GPT-5.6](https://openai.com) "Sol Ultra" at an isolated WordPress checkout — `.git` history stripped so the model couldn't cheat off changelogs — and adapted a prompt from OpenAI's math-conjecture work, the one built to keep the model from collapsing onto a single promising line of attack too early. He ran up to four agents for a minimum of six hours and let them grind. The registry-of-approaches instruction matters more than it sounds: the failure mode of LLMs on hard problems is premature convergence, and a security chain like this only exists because the model kept dead-end branches alive long enough to connect them. His claim — that no researcher could have found *and* completed this chain in ten hours even if handed the starting bug — is plausible and, notably, the defensible version of the story. Forget the $500k. The real number is that a labor task worth days of a senior specialist's time collapsed into an overnight batch job costing less than lunch. ## Who this actually hurts If you run WordPress, this is not a think-piece; it's a fire drill that mostly already happened. Patches landed in 6.9.5 and 7.0.2, and the WordPress.org team took the rare step of forcing security auto-updates on affected 6.9.x and 7.0.x installs. The attack has no preconditions — anonymous user, stock install, no plugins required — which is why it moved so fast. [watchTowr](https://watchtowr.com) reported first signs of in-the-wild exploitation within a day, and [VulnCheck](https://www.vulncheck.com/blog/wp2shell) had verified more than two dozen distinct public PoCs by July 19. If your instance is on a version older than the patch and somehow didn't auto-update — managed host with updates disabled, a pinned enterprise fork — you should assume compromise, not risk. The strategic loser here isn't WordPress specifically. It's every large, old, organically-grown codebase that has been quietly protected by the fact that chaining its weaknesses into a weapon was too tedious to bother with. That "too tedious to bother with" moat is exactly what a fleet of cheap agents dissolves. Security through obscurity was always a myth; security through *effort asymmetry* was real, and it's the thing eroding. ## The asymmetry cuts both ways — barely The optimistic read is that defenders get the same tool. Kues's methodology is reproducible: point an agent fleet at your own dependencies before someone else does. That's genuinely new capability for a mid-sized team that could never afford a dedicated offensive researcher. I'd temper it. Attackers get to run the exhaustive search once and sell or weaponize the result to everyone; defenders have to run it continuously across a sprawling dependency tree, triage a flood of maybe-findings, and still ship product. The economics favor whoever benefits from a single expensive search producing a broadly reusable artifact — and that's the attacker. What wp2shell really demonstrates isn't that AI writes exploits. It's that the cost of *building an exploit chain from a known weakness* just fell through the floor, and our entire patch-management cadence was implicitly priced on that cost staying high. The $500k was never the point. The $25 was. ## Sources & further reading - [Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25](https://slcyber.io/research-center/exploit-brokers-pay-500000-for-a-wordpress-rce-i-found-one-with-gpt5-6/)— slcyber.io - [Exploit brokers pay $500k for WordPress RCEs. I found one with GPT5.6 and $25](https://news.ycombinator.com/item?id=48975665)— news.ycombinator.com - [WordPress Core wp2shell RCE flaws get public exploits, patch now](https://www.bleepingcomputer.com/news/security/wordpress-core-wp2shell-rce-flaws-get-public-exploits-patch-now/)— bleepingcomputer.com - [Unauthenticated RCE Vulnerability in WordPress core (wp2shell), via SQL injection](https://www.aikido.dev/blog/unauthenticated-rce-in-wordpress-wp2shell)— aikido.dev - [WP2Shell WordPress Vulnerabilities Exploited in the Wild](https://www.securityweek.com/wp2shell-wordpress-vulnerabilities-exploited-in-the-wild/)— securityweek.com - [WP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030](https://www.vulncheck.com/blog/wp2shell)— vulncheck.com [Ji-ho Choi](https://sourcefeed.dev/u/jiho_choi)· Security & Cloud Editor Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept. ## Discussion 0 No comments yet Be the first to weigh in.