wp2shell: A Stock WordPress RCE, Found in Ten Hours for $25

On 17 July 2026 Searchlight Cyber published wp2shell, a pre-authentication remote code execution chain in WordPress core that needs no plugin, no theme and no login. An anonymous request against a stock install is enough: "The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins," the company's advisory states. The chain joins two bugs — CVE-2026-63030, a route-confusion flaw in the WordPress REST API's batch endpoint that the project's advisory labels critical, and CVE-2026-60137, an SQL injection in the author__not_in parameter of WP_Query that it labels moderate. WordPress released WordPress 7.0.2 the same day, and the project's advisories list WordPress 6.9.5, WordPress 6.8.6 and WordPress 7.1 beta2 as carrying the same fixes. Searchlight cites estimates of more than 500 million WordPress sites. The researcher behind the chain, Adam Kues, says it came out of a GPT-5.6 Sol Ultra run built on a prompt OpenAI had published for a mathematics problem: up to four agents, at least six hours on the hunt and about four more on escalation, roughly $25 of model usage. The record is filed as a research finding — high severity on the archive's own scale, A-grade confidence, no recorded real-world harm, dated to a single day — and the Orca AI Incident Archive carries it with the primary documents linked beneath it.

The disclosure was coordinated. Searchlight withheld the mechanics on 17 July and gave defenders the weekend to upgrade; Kues published the full technical account on 20 July. By then the chained exploit had already been reproduced independently: Searchlight says Calif and Hacktron rebuilt the full chain before other proofs of concept surfaced on GitHub. WordPress's own two security advisories name the same fixed versions, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 21 July.

Two bugs, and the arrays that fall out of step

The entry point is a feature rather than a mistake. WordPress 5.6 introduced the batch endpoint in 2020 so that a client could send several virtual REST requests inside one HTTP request, for example to retitle a set of posts at once. The endpoint is reachable whether or not the caller is authenticated, and each subrequest carries whatever authentication the caller supplied. A direct request to a WordPress REST route runs a four-step pipeline: check required and valid parameters, sanitise them, run the permission callback, then execute the endpoint callback. Endpoints rely on that pipeline for their type assumptions — that a post ID is an integer, that a title is a string.

The batch API splits the pipeline in two, validating every subrequest in one loop and executing them in a second, and it keeps two arrays, $matches and $validation, whose entries are meant to line up index for index. In class-wp-rest-server.php, as Kues describes it, a subrequest that is itself a WordPress error gets appended to $validation and then hits a continue, skipping the line that appends to $matches. From that point every match is shifted back one position. The execution loop pairs the subrequest at one index with the validation recorded at that index but the handler matched to a different route — so a parameter is checked against one endpoint's rules and then executed by another's code.

That is what turns an ordinary-looking list parameter into injection. The posts collection route maps its public author_exclude argument onto author__not_in. When the value is an array, WordPress runs absint over every element and sorts them; when the value is a scalar, it is concatenated untouched into the SQL fragment that becomes NOT IN ($author__not_in). A string such as 0) OR 1=1 -- therefore lands in the query text. Called normally the route would refuse it, because author_exclude must be an array of integers; the desynchronised batch call is what lets a string through.

Two obstacles remained, and both were solved by nesting the trick. The batch API rejects GET requests, and the injection lives on a GET route; and validation of the request method is itself implemented as parameter validation, which the same desync can bypass. Kues's published payload sends a malformed outer subrequest to desynchronise the method check, then an inner batch whose second subrequest carries the malicious author_exclude against a handler that does not validate it, then the GET that runs it. A UNION-based injection returns arbitrary database values inside rows shaped like ordinary posts.

The model run: a maths prompt, pointed at a codebase

Kues did not write the prompt from scratch. OpenAI had published the prompt it used while working on the Cycle Double Cover conjecture, and Kues wrote that he had read the model had recently solved that conjecture and that nobody in the security community seemed to be talking about the prompt. His reasoning was that if it was good enough for hard mathematics it was probably good enough for security research. He adapted it and pointed it at WordPress.

The setup was deliberately narrow. He cloned the latest stable WordPress release into a directory called main/ and deleted its .git directory, telling the model not to use changelogs, git history or the open internet to diff the code against a patched version — his stated reason being that for novel vulnerability discovery, consulting history or the web is a waste of tokens. An empty third_party/ directory was offered so the model could clone dependencies such as PHP or MySQL source if it judged that the chain needed bugs in the libraries underneath WordPress. The task was specified as pre-authentication RCE in a typical production deployment on MySQL, with up to four agents and at least six hours. Kues wrote that he states the configuration requirement explicitly because models otherwise "cheat" — by choosing extremely unlikely configuration options, or by fabricating preconditions an attacker could never achieve.

What came back, in the running output, was a claim of a pre-authentication SQL injection. Kues doubted it: WordPress is among the most heavily audited targets of all time, he wrote, and had not had a meaningful pre-authentication vulnerability that decade. He installed a stock WordPress instance on a remote server and asked the model to steal the administrator's email; within a couple of minutes it printed the address he had used to set the instance up. He then asked whether the read-only injection could be escalated, and about four hours later the model answered that it could — to administrator, without cracking any password and without offline computation.

His own costing: 50% of a weekly usage allowance, which he put at roughly $25 pro-rata on a $200 subscription, for an exploit produced in just over ten hours. The human part was not free — Kues spent the following day unpicking what the model had done, and wrote that the post-exploitation work took him much longer to understand than it had taken to generate. His verdict is unusually blunt and narrowly bounded: "I make no general claims, but I can say with complete confidence that no security researcher could have found and completed this exploit chain in 10 hours without AI."

From a read-only SELECT to administrator

The escalation is the part of the record that matters most, because it is where a database read became control of the server. Kues's account runs it as a sequence of six moves, each using an ordinary WordPress feature against another.

First, poison the in-memory post cache. WordPress keeps a per-request cache of WP_Post objects so that the same post referred to several times in one request costs one database round trip. The SQL injection can fabricate posts, so the attacker controls exactly what gets cached — but those fabricated posts are not rows in the database, and the cache dies with the request.

Second, turn fabricated posts into real rows. WordPress's embed feature caches resolved embeds in the database as posts of type oembed_cache. Embedding a local post by relative path, as in [embed]/?p=S[/embed], makes WordPress skip the HTTP fetch and never check that the referenced post exists, so a row is created. Three such embeds with different query-string tokens produce three different cache hashes, which is how the attacker gets several rows to work with.

Third, work around the one field that stays fixed. When the in-memory and database versions of a post disagree, WordPress reconciles them with a call that explicitly sets post_content from the embed output. Everything about the post is attacker-controlled except its content, which is precisely the field a customize_changeset uses to store the JSON of pending theme and site changes.

Fourth, the cycle gadget. Posts have parents, and WordPress refuses cycles: the wp_insert_post_parent filter walks up the tree and, on finding a loop, calls an update that sets post_parent to zero. That call does not overwrite post_content, so the fabricated in-memory version survives reconciliation — a changeset, with its JSON intact, backed by a real row.

Fifth, borrow the administrator's authority. A changeset whose status says it is scheduled for the future but whose date is in the past gets applied immediately. Each entry in its JSON names a user_id, and the entry in Kues's chain names user_id 1, the administrator, so WordPress temporarily adopts that identity to apply the change. The first change is a harmless-looking update to nav_menus_created_posts.

Sixth, replay the request as that identity. Publishing a post fires a dynamically named action, {status}_{post_type}. Because the post is fabricated, that status and type can be anything — including parse and request, which yields the parse_request hook and restarts the request pipeline from the top while the borrowed administrator identity still holds. The original batch request contained a subrequest creating a new administrator; it failed on the first pass as a guest and succeeds on the replay. From there the attacker logs in as that new account and uploads a backdoor plugin from a ZIP file, which is code execution.

The technique has a condition attached. The Hacker News, citing Cloudflare, reported that CVE-2026-63030 yields remote code execution only when a persistent object cache is not in use; the injection itself is present from WordPress 6.8, while the full chain needs 6.9 or later. A stock installation has no persistent object cache, which is why Searchlight's "no preconditions" phrasing and Cloudflare's qualifier describe the same default case from different directions.

What the primary documents establish

WordPress's own advisories are the strongest corroboration, because they are the vendor conceding the mechanics and shipping the repair. GHSA-ff9f-jf42-662q, rated critical, describes a REST API batch-route confusion weakness in WordPress 6.9 and higher that combines with the injection to reach code execution, and credits Adam Kues at Assetnote and Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, rated moderate, describes the author__not_in injection from WordPress 6.8 and higher, and states that both issues are fixed in WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 and WordPress 7.1 beta2. The NVD records for the two CVEs, scored by the WPScan CNA rather than by NIST, carry 9.8 for CVE-2026-63030 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and 5.9 for CVE-2026-60137 with AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — a network-reachable, no-privileges-required bug in the first case, and one that requires high attack complexity and yields confidentiality impact only in the second. The archive's own severity field for this entry reads high while WordPress labels the batch flaw critical; the two are separate scales applied to a whole chain and to a single component, not a disagreement about the bugs themselves.

CISA's catalog entries, as reflected in NVD's enrichment fields, were added on 21 July 2026 with remediation deadlines of 24 July for CVE-2026-63030 and 4 August for CVE-2026-60137. CISA names the first "WordPress Core Interpretation Conflict Vulnerability" and the second "WordPress Core SQL Injection Vulnerability". Searchlight also published a public checker at wp2shell.com so that operators could test an instance without waiting for a scanner signature.

The independent reproduction is documented by Searchlight itself and is therefore a claim about third parties rather than a third-party account: Calif and Hacktron rebuilt the full chain before other proofs of concept appeared on GitHub, according to the 20 July write-up. What is verifiable independently is the effect — proofs of concept, exploitation traffic and vendor telemetry within days, covered below.

What is claimed but not established

Two credits for one injection do not reconcile in the public record. WordPress's advisory for CVE-2026-60137 states that the flaw was "discovered and responsibly disclosed as a team by TF1T, dtro, and haongo". Searchlight's account presents the same pre-authentication injection as what its model run surfaced, and does not mention that team; WordPress's advisory credits Kues only for the batch-route confusion, and does not mention a model. Neither document explains the overlap, and nothing this piece located resolves it — the possibility that the two were independent findings of the same bug is not excluded, and the possibility that one report is a later re-discovery is not established either. The record does not adjudicate it, and neither does this article.

The headline number in Searchlight's 20 July post is not supported by its own body. It reads "Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25". The body documents the $25 and the ten hours in specific terms; it carries no broker names, no offers, no correspondence and no source for the $500,000 figure. No independent report located for this piece corroborates a price paid or offered for wp2shell. Read the $500,000 as the framing of the headline, not as an established market price.

The archive entry's own scope is narrower than the story around it. It records a research finding on the disclosure day, flags no real-world harm, and is dated to a single day, 17 July 2026. That is not a claim that nothing happened afterwards: exploitation traffic was reported within hours of the advisory, and CISA catalogued both CVEs four days later. The flag covers what the entry describes — the discovery and the coordinated disclosure — and the subsequent exploitation is documented by other parties on their own evidence, below.

Exploitation after the advisory

Jake Knott, principal security researcher at watchTowr, told The Hacker News that "by the early hours of Saturday morning (UTC), successful exploitation was already well underway, initially using public exploit code to exfiltrate hashed credentials, with remote code execution following once additional details were made public." The same report cites KEVIntel telemetry linking 13 unique IP addresses, from Switzerland, Germany, the United Kingdom, Indonesia, Lithuania, the Netherlands and Singapore, to exploitation of CVE-2026-63030, and quotes KEVIntel founder Ryan Dewhurst saying that requests matched publicly available proofs of concept and that blind, UNION-based and boolean-based payloads were all used.

Wiz's researchers Shahar Dorfman and Gili Tikochinski, publishing on 20 July, put scale on it: 60% of organisations using WordPress had at least one vulnerable instance at the time the CVEs were published and 25% were exposing a vulnerable server to the internet, falling to 50% and 10% within 24 hours as patching began. They recorded malicious plugin uploads through the admin installer, user enumeration against the users endpoint, local file inclusion attempts against wp-config, and admin panel access returning HTTP 200 — the signature of a successful login rather than a probe. The malware they found spanned a minimal one-line PHP backdoor and a 150 KB webshell disguised as a legitimate WordPress security plugin called CMSmap, with file management, database access, port scanning and privilege-escalation modules.

Wiz also recorded a limit on what can be concluded. High-volume scanning without post-exploitation was common, consistent with opportunistic mass scanning and with legitimate security scanning, and the firm stated that it had not identified lateral movement or data exfiltration. That is a statement about what one vendor's telemetry showed, not a finding that nothing was taken.

What changed afterwards, and what stayed open

For operators, the response path was short. Updating to WordPress 7.0.2, WordPress 6.9.5 or WordPress 6.8.6 is the fix. Searchlight's emergency alternatives, for sites that could not update immediately, were to block anonymous access to the batch API — either by installing a plugin that blocks anonymous access to the REST API entirely, or by blocking /wp-json/batch/v1 and ?rest_route=/batch/v1 at a web application firewall. The company warned that both can affect legitimate use of the site and should be treated as temporary measures until the update lands. The public checker at wp2shell.com tests an instance directly. CISA's catalog entries added a compliance clock: remediation by 24 July for CVE-2026-63030 and by 4 August for CVE-2026-60137.

For the research question, the part that did not resolve is what the model actually contributed relative to its operator. Kues is precise about the division: the model produced the chain in roughly ten hours, and understanding it took him longer than generating it had. He declines general claims and says only that the ten-hour result was not reachable by a human unaided. The prompt itself is not a secret — it derives from one OpenAI published, and Searchlight reproduced its structure in the write-up, including the instruction to ignore version history and the requirement that the exploit work in a typical production configuration. Whether that recipe transfers to other codebases is exactly the question Kues says he is not answering, and no second run has been published.

What the record leaves unestablished is therefore narrow but consequential: which of the two credited parties first found the injection, whether any broker ever paid the figure in the headline, and what, if anything, the webshells Wiz observed actually took from the sites they landed on. On the last point the only public statement is Wiz's, that it has identified no lateral movement or data exfiltration — an absence of evidence from one vantage point, offered as such.