AI security

An AI found a WordPress zero-day for $25. Read the fine print.

On 20 July 2026 a security researcher published a claim that reads like the headline the whole industry has been bracing for: he found a critical, unauthenticated way to run code on WordPress, the software behind a large share of the world's websites, using OpenAI's GPT-5.6 and about $25 of model usage. The title reaches further still, noting that exploit brokers pay $500,000 for a bug like this. That claim is either the most important thing to happen in software security this year or a careful piece of marketing. It is a bit of both, and the useful skill this week is telling which part is which.

Dated analysis. Written 20 July 2026. The vulnerability is drawn from WordPress's own advisory and reporting by BleepingComputer and The Hacker News; the story of an AI finding it comes from the researcher's own write-up at Searchlight Cyber; the wider capability picture from the UK AI Security Institute (via Fortune) and OpenAI's own system card. Below I keep three things apart: what is independently confirmed, what is one person's first-hand account, and what is framing.

What is actually confirmed

Start with the part that does not depend on anyone's story. A zero-day is a flaw that is exploitable before a fix is widely deployed, so defenders have had zero days to prepare. This one is nicknamed wp2shell, and it is real: two chained bugs in WordPress Core, tracked as CVE-2026-63030 and CVE-2026-60137, that together give an anonymous attacker pre-authentication remote code execution - the ability to run their own commands on the server without logging in - against a default install with no plugins. WordPress shipped fixes in versions 6.8.6, 6.9.5 and 7.0.2, public proof-of-concept exploit code appeared on GitHub within days, and by 20 July several security firms were reporting the flaw under active exploitation in the wild. This much is corroborated across multiple security outlets, not a single source.

One number needs correcting straight away, because the headline invites the wrong read. Yes, over 500 million sites run WordPress. No, they are not all exposed to takeover. The full code-execution chain only affects the recent releases, roughly the versions shipped since December 2025 (6.9.x and 7.0.x); the SQL injection on its own reaches back into 6.8.x but does not, by itself, hand over the server. The honest sentence is narrower than the headline: if you run a current WordPress, you were briefly one request away from a stranger owning your site, and you should patch today.

A worked example: from a public request to running code

The chain is worth walking through slowly, because seeing it makes the AI part easier to judge. WordPress has a batch API: an endpoint that lets you bundle several ordinary requests into one call, a convenience for apps that talk to a site. The first bug is a routing mistake in how those bundled sub-requests are checked, which lets one of them run without the permission it should have needed. The second is a SQL injection: an old, well-understood class of flaw where user-supplied text is fed into a database query as if it were code, so a crafted value in the author__not_in parameter makes the database return rows the attacker chose rather than the ones the site meant to serve.

How wp2shell walks from an anonymous request to running code

Two chained flaws turn a public API into an unauthenticated takeover: no login, no plugins, a stock WordPress install on an affected version.

  1. Bundle several requests WordPress lets one unauthenticated call to the batch endpoint carry several sub-requests at once. Entry point
  2. Slip past the auth check A routing and validation mismatch lets a sub-request run without the permission it should require. CVE-2026-63030
  3. Inject SQL A crafted author__not_in value rewrites the database query so it returns fabricated rows the attacker controls. CVE-2026-60137
  4. Borrow administrator rights Cache and changeset manipulation makes the site treat the anonymous caller as an admin for one replayed request. Privilege escalation
  5. Run code That replayed request now executes with admin rights: full remote code execution on a default install. Pre-auth RCE

A stock, plugin-free WordPress on an affected version can be taken over by anyone who can reach it over the network.

The chain, in five movesEach step is ordinary on its own. Chained, they carry a request from the open internet all the way to executing code as an administrator - which is why the fix is to patch the core, not to reconfigure a setting.

None of the individual moves is exotic. What is striking is the assembly: a long, patient sequence of small, legal-looking steps that each nudge the system further off its rails, ending with the site running the attacker's code as an administrator. (The cache-and-changeset route above is the discoverer's; other public exploits reach the same place a cruder way, by dumping the database and cracking an administrator's password hash.) Building that chain by hand is exactly the slow, expensive part of exploit work.

Now the part that is one person's account

The researcher is Adam Kues of Searchlight Cyber's Assetnote team, and his write-up is a first-person account, not an independent finding I can reproduce here. By his telling, he pointed a four-agent setup at WordPress for a few hours; the model reported a pre-authentication SQL injection and wrote the escalation to code execution in roughly four hours, at a cost he pro-rates to about $25 of his monthly subscription. He then spent about a day working out what it had actually done, and says plainly that no researcher could have completed this chain in ten hours without AI - while adding that the "meta skills", deciding what to attack in the first place, are still handled poorly by the model.

That last caveat is the whole story, and it is easy to skip past. The human chose the target, ran the model against live systems, validated its claims, and did the work of understanding an exploit chain convoluted enough that its own commissioner needed a day to follow it. This is the argument for a separate, competent checker: the value here was not the model producing text, it was an expert with a tightly scoped agent loop who could tell a real finding from a confident-sounding wrong one.

What is framing, and what actually changed

Two numbers are doing persuasion work. The $500,000 is an order-of-magnitude market comparison, not a receipt: nobody paid it, no sale happened, and practitioners on Hacker News were quick to note that a buyer who can prompt the same model themselves has little reason to pay a broker at all. The $25, meanwhile, quietly omits the years of domain expertise the human brought and the failed runs a single success story never shows. Both figures are true and both are marketing. Read them the way you would read a vendor benchmark: as a claim measured under flattering conditions, not a promise about your situation.

Strip the framing away and something real is still left. It is not that "AI can now hack" - models have surfaced vulnerabilities for a while, and plain static-analysis tools have caught SQL injection for two decades. What changed is narrower and more consequential: the cost and time of turning a chosen weak target into a working exploit collapsed for someone who already knows what they are doing. And the direction is corroborated beyond one write-up. The UK AI Security Institute, testing GPT-5.6 independently, found "universal jailbreaks" that unlock it for long-horizon vulnerability discovery and exploit development. OpenAI's own system card reports the model surfacing bugs and exploitation primitives in real software, though short of a full working exploit on its own. A separate pipeline, unrelated to this case, surfaced more than 300 WordPress-plugin zero-days in 72 hours at around $20 each. The wp2shell story is one vivid data point on that trend, not the trend itself.

What this means if you run anything

The defender's consequence is the part that survives Monday morning. When a patch ships, it also publishes the bug, because anyone can compare the old code with the new and see what was fixed. The window between "patched" and "mass-exploited" used to be measured in weeks, because writing a reliable exploit was slow, skilled labour. As that labour gets cheap, the window shrinks toward hours. Your real exposure is no longer whether a fix exists; it is how fast you apply it. For a WordPress site that means updating to 6.8.6, 6.9.5 or 7.0.2 now and checking for signs of compromise. For everyone else it means treating patch latency, not patch availability, as the metric that matters.

It is worth remembering who inherits this. The person running WordPress for a sports club, a school newsletter or a parents' association is no one's $500,000 target - but the cost of reaching them just fell to something an opportunist can automate at scale. Cheap exploitation does not care that a site is small, and the web's unmaintained corners are where a widening dragnet lands first.

Where this reading could be wrong

Two honest caveats. First, the AI-discovery specifics are one credible person's account: the vulnerability itself is independently confirmed and now being exploited, but the exact role the model played, the four hours and the $25 rest on his word and have not been reproduced elsewhere. Second, the economics could be overstated in either direction - a WordPress remote-code-execution bug may be worth less than the headline suggests, or the "expert still required" caveat may erode faster than I expect as the tools improve. The safe conclusion is the narrow one: a real, serious WordPress flaw exists and is being weaponised, a capable model materially sped up building the exploit, and the gap between disclosure and exploitation is closing. Patch on that basis, not on the $25.

Questions people ask

What is wp2shell? A chain of two WordPress Core vulnerabilities, CVE-2026-63030 (a REST batch-route confusion) and CVE-2026-60137 (a SQL injection), that together let an unauthenticated attacker run code on a default WordPress site. It affects 6.9.0-6.9.4 and 7.0.0-7.0.1, with the SQL injection alone reaching into 6.8.x, and is fixed in 6.8.6, 6.9.5 and 7.0.2.

Did an AI really find it for $25? A named researcher published a first-person account of using GPT-5.6 to build the working exploit for roughly $25, pro-rated from his subscription. The bug is independently confirmed; the AI-discovery story is his own account and has not been independently reproduced.

Are all 500 million WordPress sites at risk? No. That figure is total WordPress usage; the full takeover chain only affects recent versions released since about December 2025. Patch 6.9.x and 7.0.x now.

Does this mean AI can hack anything? No. It means turning a chosen weak target into a working exploit got cheap and fast for an expert who directs the model and checks its work. Choosing the target and validating the result is still human.


Sources & caveats. The vulnerability, CVE identifiers, affected and patched versions and the existence of public exploits are corroborated across BleepingComputer and The Hacker News; early reports on 18 July had not confirmed in-the-wild exploitation, but by 20 July several firms reported it under active attack. The AI-discovery account, the $25 and $500,000 figures and the four-hour timeline are from Adam Kues's write-up at Searchlight Cyber (20 July 2026) and are his first-person claims, not results reproduced here; sceptical counterpoints are drawn from the Hacker News discussion. For the wider capability picture, GPT-5.6's "universal" cyber jailbreaks are an independent UK AI Security Institute finding reported by Fortune; the model surfacing bugs and exploitation primitives (short of a full autonomous exploit) is from OpenAI's own GPT-5.6 system card, a vendor self-report; and the ~$20-per-bug plugin pipeline (TrendAI and CHT Security) is reported by Help Net Security. The "exploit development got cheap" and "patch latency is the exposure" readings are my analysis, not reported fact.