The WordPress RCE found with an AI agent is a patch-management warning, not a magic trick

A security researcher says GPT5.6 Sol Ultra helped find and chain a pre-authentication WordPress core vulnerability into remote code execution; the practical lesson for software teams is simpler and harsher: autonomous code-reading systems have made “widely deployed, boring, open-source surface” a higher-tempo security target.

Searchlight Cyber researcher Adam Kues published a detailed write-up on July 20 describing how he used OpenAI’s GPT5.6 Sol Ultra, a multi-agent prompt adapted from an OpenAI math-reasoning example, and roughly six to ten hours of agent work to investigate WordPress core. According to Kues, the run produced an initial pre-authentication SQL injection and then a longer exploit chain that could become remote code execution on a stock WordPress installation. Searchlight calls the issue “wp2shell.”

The defensive facts are more important than the origin story. Rapid7 wrote on July 17 that a GitHub Security Advisory had been published for CVE-2026-63030, a critical unauthenticated remote-code-execution issue in WordPress Core, and said the advisory listed affected versions as WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1, with fixes in 6.9.5 and 7.0.2. WordPress.org’s download page currently offers WordPress 7.0.2. Eye Security’s July 20 defender guide identifies a two-bug chain: a REST API route-confusion bug in the batch endpoint, CVE-2026-63030, and a WP_Query SQL injection, CVE-2026-60137. Eye Security also says 6.8.0 through 6.8.5 are exposed to the SQL injection only and fixed in 6.8.6.

That version detail matters because this is not a plugin story. WordPress security incidents often concentrate around third-party extensions and themes. This one is alleged and documented as core behavior, with the entry point in the REST API batch endpoint. Searchlight’s checker says the attack has no plugin prerequisite and can affect a stock installation; Rapid7 similarly summarized Searchlight’s position as a default WordPress installation without additional plugins. Cloudflare, as cited by Rapid7, added an important narrowing condition: the vulnerable code path can be reached when a persistent object cache is not in use. That caveat may reduce exposure for some larger or more heavily engineered installations, but it is not a reason for ordinary sites to wait.

For builders, the shift is not that AI “replaced” a vulnerability researcher. Kues’s post describes a human researcher choosing a target, shaping the prompt, removing shortcuts such as git history, checking the model’s findings, reproducing the issue on a stock instance, writing the report, and then explaining the exploit chain. The model’s contribution, as he presents it, was sustained code inspection and gadget chaining across a large PHP codebase. That is exactly the kind of task modern agent systems are getting better at: not just producing a one-line bug guess, but keeping several hypotheses alive, reading source, and assembling a path through unrelated subsystems.

Kues reports that the model first found a pre-authentication SQL injection and later determined it could be escalated. In his account, the eventual chain used a mismatch in batch request validation and execution, a posts-query sink, caching behavior, embeds, changesets, parent-cycle handling, and a hook path to replay request processing with elevated authority. This article is deliberately not reproducing payloads or exploit steps. The relevant engineering takeaway is the shape of the failure: validation assumptions held locally, but composition across batching, request dispatch, database reads, cache state, and post-processing created a reachable path no single subsystem owner would necessarily see in isolation.

That is where AI-assisted security work changes the defensive clock. Open-source projects have always been auditable by attackers. The difference is that strong code-reading agents can lower the cost of long, tedious search. Kues says the run consumed about 50 percent of a weekly allocation on a $200 subscription, which he prorated to roughly $25. Treat that as the researcher’s account of his spend, not as an independently reproduced cost benchmark. The broader point still stands without the exact dollar figure: when agentic systems can examine large public codebases for hours, “nobody will bother to read all of this” stops being a safe assumption.

The market-price framing in Searchlight’s headline should also be handled carefully. The post contrasts the discovery with exploit brokers paying $500,000 for a WordPress RCE. I could not verify a current broker price list from a reader-facing source during this check, so that number should not be treated here as an independently verified going rate. It is enough to say the economic asymmetry is real: the marginal cost of repeated AI-assisted analysis is falling, while the value of a remotely exploitable bug in ubiquitous software remains high.

What should practitioners do now?

First, verify the running WordPress version rather than assuming auto-update worked. If a site is on the 7.0 branch, the fixed release named by Rapid7 and the public checker is 7.0.2. If it is on the 6.9 branch, the fixed release is 6.9.5. If it is maintained on 6.8, Eye Security says 6.8.6 addresses the SQL-injection-only exposure it describes. The public checker at wp2shell.com says versions before 6.9.0 are not affected by the full wp2shell RCE path, which is a narrower claim than Eye Security’s SQLi-only branch note. The safest operational reading is: confirm the exact branch, apply the relevant security update, and do not flatten “not full RCE” into “no action required.”

Second, look for compromise, not just vulnerability. Eye Security warns that the absence of obvious access-log entries is not enough, because important steps can ride inside batch POST bodies that many logs do not retain in useful detail. Its guide emphasizes database artifacts, unexpected administrators, suspicious file timestamps, and web-root changes. That is a better posture for this class of bug than grepping access logs and declaring victory.

Third, harden the route only as a bridge, not as a substitute for patching. Searchlight’s checker page recommends updating immediately and lists temporary mitigation options including disabling unauthenticated use of the WordPress API or blocking the batch route and related REST route pattern at a WAF. Those steps can buy time for a constrained environment, but they can also break legitimate workflows. They should be scoped, tested, monitored, and removed or relaxed after patching where appropriate.

Fourth, update threat modeling for public source dependencies. A team that ships software on top of WordPress, Laravel, Rails, Electron, Kubernetes operators, npm packages, or Python frameworks should expect more model-assisted audit work against those stacks. The answer is not secrecy; public source remains vital for review and trust. The answer is to invest in compositional tests, fuzzing around dispatch and validation boundaries, and security review for “boring glue” features such as batching, caching, embedding, serialization, and permission callbacks.

Fifth, prepare for faster disclosure pressure. Once a patch lands in an open-source project, capable humans and AI systems can diff, inspect, and build working probes quickly. Rapid7 wrote on July 17 that it was not aware of publicly confirmed in-the-wild exploitation at its publication time, but Eye Security’s July 20 guide tells defenders to treat the issue as actively exploited and act immediately. Those statements are not necessarily contradictory; they reflect a fast-moving disclosure window. The operational decision should not wait for perfect public certainty when the affected software is internet-facing and the fix is available.

The most consequential part of Kues’s write-up is not whether GPT5.6 Sol Ultra is “superhuman,” a word he uses in a question heading before giving a narrow first-person assessment. The durable story is that agentic vulnerability research now has a plausible workflow: choose a large target, constrain the agent against shortcuts, run multiple approaches, demand adversarial checking, and let the system search across subsystem seams longer than a human team might justify for one speculative lead.

That workflow helps defenders too. Maintainers can point agents at their own code before release, assign them to incompatible search strategies, and require proof that a finding survives validation, permissions, and realistic deployment constraints. Application teams can use the same lesson for internal code: search where assumptions cross process boundaries, not just where a linter already knows to complain.

WordPress site owners should patch now. Software teams should read this incident as a preview of the next maintenance reality: AI agents will not make every bug shallow, but they will make deep, patient codebase inspection cheaper. Security programs built around quarterly review cycles and hope are going to feel that first.

Sources

• Searchlight Cyber: Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25
• wp2shell checker: Pre Authentication RCE in WordPress Core
• Rapid7: CVE-2026-63030 — wp2shell a Critical Remote Code Execution Vulnerability in WordPress Core
• Eye Security: wp2shell incident response guide, CVE-2026-63030 and CVE-2026-60137
• WordPress.org: Download WordPress
• W3Techs: Usage statistics and market share of WordPress, July 2026

---

Shadowfetch is an independent news publication. Explore Shadowfetch Linux — our own Linux build — and the Shadowfetch apps on the App Store.