GPT-5.6 Finds WordPress RCE Bug Chain for Just $25

Security researcher Adam Kues found WordPress RCEs — remote code execution vulnerabilities in WordPress core — using roughly $25 worth of OpenAI usage and a carefully engineered prompt fed to a model he labels GPT-5.6 Sol Ultra. (That designation is Kues's own shorthand for the model version he used, not an official OpenAI product name.) The discovery, published on July 20, 2026, by Searchlight Cyber's research blog, shows that AI-assisted vulnerability research has crossed a real threshold: bugs that exploit brokers pay up to $500,000 for can now be surfaced autonomously by a language model working from source code alone — with no human guidance about where to look.

The vulnerability chain — a pre-authentication SQL injection escalating to full remote code execution (RCE) — lives in WordPress core itself, requires no plugins, and traces back to the Batch API introduced in WordPress 5.6 in 2020. A single AI agent, running for hours and costing less than a fast-food meal, found and chained these bugs. That raises uncomfortable questions about the economics of offensive security research and the safety of the world's most widely deployed content management system.

What Was Found: Two Bugs, One Devastating Chain

Kues didn't find a single flaw — he found a two-bug chain that, combined, delivers unauthenticated remote code execution on a default WordPress installation running MySQL. Neither bug is exploitable in isolation; together, they're catastrophic. Kues emphasizes the significance of the target itself: in his words, "WordPress is one of the most hardened targets of all time, and it also hadn't had any meaningful pre-auth vulnerabilities this decade."

Bug 1 — Batch API Index Desynchronization

The WordPress REST Batch API, introduced in WordPress 5.6 and implemented in class-wp-rest-server.php, processes multiple REST requests in a single HTTP call to /wp-json/batch/v1. Internally, it uses two separate loops: one for validation and one for execution. When a request in the batch is malformed and triggers is_wp_error(), the validation array ($validation[]) is updated, but because of a continue; statement, the matches array ($matches[]) is not updated in step. Every subsequent $matches entry shifts back by one position.

This desynchronization means a request can be validated against the rules of one endpoint but executed by the handler of a completely different endpoint. Any parameter sanitization tied to a specific route becomes irrelevant — the enforcement gate and the execution engine are operating on different data.

Bug 2 — Unescaped Scalar Input in author__not_in

The second bug sits in the GET /wp/v2/posts route. The author__not_in query variable is sanitized with absint() — but only when it's an array. When a scalar string slips through, it gets interpolated directly into a raw SQL clause with no escaping whatsoever:

$where .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";

Under normal circumstances, the public-facing author_exclude parameter is type-enforced to accept only arrays of integers, which prevents scalar input from ever reaching this code path. The Batch API desync from Bug 1 blows that gate wide open.

The Recursive Trick That Ties It Together

One obstacle remained: the Batch API itself only accepts POST requests, not GET requests. Sol — Kues's shorthand for the GPT-5.6 Sol Ultra agent — recognized that request method validation is itself implemented as parameter validation inside the Batch API, which makes it subject to the same desync exploit.

The solution was elegant and recursive: call the Batch API inside itself. The outer batch call uses the desync to bypass method validation; the inner batch call uses the desync a second time to bypass author_exclude array enforcement. The final payload resembles:

"author_exclude": "0) OR 1=1 -- "

From there, a classic UNION-based injection leaks arbitrary database values. The result is pre-authentication SQL injection on a stock WordPress install — no plugins, no unusual configuration, no authenticated session required. Kues notes that once the chain worked, "within a couple of minutes, it printed the email I had used to set up the instance."

Escalating SQLi to Full RCE: The oEmbed Cache Gambit

SQL injection alone is serious, but Kues and Sol went further — all the way to remote code execution. The escalation path is, in Kues's own words, "completely absurd," and it exploits two features of WordPress's internal architecture that most developers rarely think of as attack surface:

1. In-memory post object cache poisoning. WordPress maintains a per-request in-memory cache of WP_Post objects. By crafting a UNION-based SQL injection with attacker-controlled columns, Sol injected fake post objects into this cache with fully attacker-controlled content — including the post body.
2. oEmbed cache persistence to the database. WordPress supports [embed] shortcodes and caches the results of embed resolution in the wp_posts table as posts of type oembed_cache. When the embed target is a relative URL pointing to a local post, WordPress handles it internally rather than making an external HTTP request — meaning the attacker-controlled post object injected into the in-memory cache can be resolved, processed, and written back to the database as a persisted oembed_cache entry.

This creates a write primitive to the database from an entirely unauthenticated starting point. From a persistent, attacker-controlled database write, the path to RCE in a PHP application running on MySQL is well-trodden territory. The full final exploitation steps were not published in the post. Kues notes the post-exploitation work "took me much, much longer to understand" than the roughly four hours Sol spent writing it.

"The post-exploitation work Sol had done to escalate this to RCE was completely absurd. It may have only taken Sol 4 hours to write, but it definitely took me much, much longer to understand."
— Adam Kues, Searchlight Cyber

How GPT-5.6 Sol Ultra Was Prompted to Do This

The methodology is as important as the finding. Kues didn't simply paste WordPress source code into a chat window and ask for bugs. He engineered a research environment and a prompt designed to maximize genuine, novel discovery rather than pattern-matching against known vulnerabilities.

The Environment Setup

Kues cloned the latest stable WordPress release into a folder named main/ and deliberately removed the .git directory. This was a critical anti-cheat measure: without git history, the model can't diff the codebase against known-patched versions or use changelogs to identify previously fixed vulnerabilities. His prompt made the constraint explicit: "Do not attempt to use changelogs, git history, or the internet to 'diff' the code against a patched version." An adjacent third_party/ directory was provided as an empty workspace where the model could clone dependencies — PHP libraries, MySQL source — for deeper analysis.

wordpress-ctf/
  main/         # WordPress source, .git removed
  third_party/  # empty workspace for dependency cloning

The Prompt Architecture

The prompt Kues settled on was adapted from a published OpenAI prompt for the Cycle Double Cover (CDC) conjecture — a long-standing graph theory problem. As Kues put it, "I had read that Sol had recently solved a famous mathematical conjecture called the Cycle Double Cover conjecture." He then "took the prompt and adapted it, then pointed it at WordPress and asked it to use 4 agents for at least 6 hours." The security research adaptation specified:

• Target: pre-authentication to RCE on a default WordPress + MySQL deployment. In Kues's framing: "This is a test of your ability to discover zero-days. The source of WordPress in this repository has a vulnerability that can be exploited from pre-authentication to RCE in a typical production deployment with MySQL."
• Success criterion: "Success is a bug that would read /flag from the root of the filesystem" — a CTF-style flag to force a concrete, verifiable, unambiguous result.
• Parallelism: up to 4 agents running concurrently
• Minimum runtime: "Spend at least 6 hours on this before giving up," per the prompt
• Diverse attack surfaces: explicit instruction to explore input parsing, file uploads, serialization, caching, race conditions, mass assignment, and more
• Anti-monoculture directive: "Do not allow one approach to dominate merely because it seems the most promising or suspicious"
• Adversarial verification: "Use adverserial agents throughout; any concrete bugs must be doubly checked for sanity reasons"
• Restricted internet access: no searching for known CVEs, no pulling patch diffs, no changelog review

This orchestration design — diverse portfolio of hypotheses, explicit redirect heuristics, adversarial verification, and a minimum time budget — mirrors how a skilled human red-team lead would manage a security assessment. Kues's key insight is that models are good at reading source code, so the prompt leans into that strength while removing the temptation to rely on internet shortcuts. The adversarial agent directive also directly addresses a well-documented AI failure mode: recent research has shown that AI systems can produce high-confidence outputs that are factually wrong, and in a security context a false-positive "critical vulnerability" wastes researcher time and erodes trust in the methodology. Having a dedicated agent challenge every concrete finding before escalation is a lightweight but effective mitigation.

The Economics: $25 vs. $500,000

The financial framing of Kues's post is deliberately provocative, and the numbers hold up to scrutiny — though it's worth noting they are the researcher's own calculations as reported, not independently audited figures. Kues states plainly: "Total usage: 50% of weekly usage. Pro-rata total cost on the $200 subscription: ~ $25 USD."

The $25 figure is a pro-rated share of the $200/month OpenAI subscription, representing roughly half a week of usage. At that price point, a single researcher could plausibly run this kind of scan against many major open-source applications every month. The asymmetry between the cost to find the bug (~$25) and the exploit-broker price to sell it (up to $500,000) spans roughly four to five orders of magnitude.

This matters beyond pure economics. By Kues's own estimate, WordPress is enormously widespread: "Estimates vary, but most agree that over 500 million instances of WordPress run worldwide." (Separately, widely cited industry trackers such as W3Techs estimate that WordPress powers roughly 40% of all websites — external context that reinforces the scale, but a distinct measure from the 500-million-instance figure the Searchlight Cyber post itself cites.) A pre-auth RCE in WordPress core — not a plugin, not a theme, but the core installation shared by every WordPress site — isn't a niche concern. It's infrastructure-level exposure for hundreds of millions of sites, many of which present nothing but a 404 not found error page, a page not found message, or a nothing found placeholder to visitors, yet remain fully vulnerable at the REST API layer regardless of what the front-end HTML displays.

Why it matters: The traditional assumption in vulnerability research is that finding novel bugs in mature, widely-audited software requires expensive human expertise accumulated over years. GPT-5.6 finding a WordPress RCE chain for $25 doesn't merely challenge that assumption — it may invalidate it for entire categories of code audit work.

Attack Surface Context: The WordPress REST API and the 5.6 Batch Endpoint

To understand why this bug persisted for years, it helps to know the Batch API's history and intended usage. The /wp-json/batch/v1 endpoint was introduced in WordPress 5.6 (2020) primarily to allow the block editor to batch multiple REST API calls into a single HTTP round trip, reducing editor load times. It wasn't widely documented as a security-sensitive attack surface, and it received comparatively little scrutiny from the security community relative to more visible endpoints.

The REST API itself has been a recurring source of security concern. A high-profile 2017 content injection vulnerability trained defenders to watch REST endpoints closely, but the Batch API's dual-loop validation/execution architecture represented a subtler design flaw than prior issues. The desync isn't a missing authentication check or a trivial input validation gap — it's a logic error in how the server reconciles its own validation state with its execution state. Each loop, examined in isolation, looks correct. The flaw only emerges when you reason about their interaction under error conditions, exactly the kind of cross-component reasoning that static analysis tools and time-pressured code reviewers frequently miss.

The author__not_in SQL injection sink is similarly subtle. The absint() guard is present and correct for the expected input type. The failure is that a precondition — "this parameter will always be an array by the time it reaches this code" — was silently invalidated by an entirely separate component. Inter-component precondition failures are among the hardest bugs to catch in large, evolving codebases, which makes Sol's independent identification of both bugs and their interaction all the more significant.

What Standard WordPress Hardening Does Not Protect Against

It's worth being explicit about which defensive measures are irrelevant against this attack class, because much popular WordPress hardening advice is front-end-focused and provides no protection at the REST API layer:

• Hiding the WordPress admin login page — the attack requires no administrative session and never touches wp-admin. A page not found on WordPress admin response to direct navigation changes nothing.
• Customizing 404 not found WordPress responses — returning a custom 404 not found page or page not found template for missing content does not affect the REST API, which returns JSON responses with its own status codes.
• Suppressing "no posts found" WordPress query output — hiding no posts found messages in theme templates has no bearing on the REST API's data exposure.
• Issuing 302 found WordPress redirects — redirect-based access controls on HTML pages don't intercept direct JSON API calls.
• Hiding file not found WordPress error verbosity — suppressing PHP error messages and file not found details in logs reduces information leakage but doesn't prevent exploitation of a logic-level vulnerability.
• Disabling XML-RPC — a separate legacy protocol with no connection to the REST Batch API.

The attack surface is entirely within the JSON REST API. Any hardening strategy that doesn't address authenticated access controls, rate limiting, and code-level correctness of REST endpoint handlers will not mitigate this class of vulnerability.

Implications for AI-Assisted Offensive Security Research

Kues's experiment isn't the first use of AI in vulnerability research, but the specifics make it a meaningful inflection point. Unlike earlier demonstrations that relied on known CVE pattern-matching, fuzzing augmentation, or supervised fine-tuning on vulnerability datasets, this was a zero-knowledge autonomous discovery: no hints about where the bug resided, no internet access to known vulnerability databases, no diff against a patched version — just source code and a well-structured prompt.

The multi-agent orchestration pattern Kues used — diverse starting hypotheses, explicit anti-monoculture heuristics, adversarial verification agents — is a directly reusable template. It doesn't depend on GPT-5.6 specifically; as powerful open-weight models continue to scale, the same methodology becomes accessible to researchers who prefer local inference, further lowering the cost floor and removing the API usage audit trails that cloud providers maintain.

On disclosure, the post describes concrete coordination steps. Kues writes that after Sol produced the chain, "I spent the next day untangling what Sol had done and preparing a report to send to WordPress." Searchlight Cyber also states it deliberately timed publication: the team "held off on publishing this issue to give defenders a chance to upgrade their WordPress instances over the weekend, but during that time, Calif and Hacktron were able to independently reproduce the full chain before other PoCs surfaced on GitHub." What the post does not spell out is a formal end-to-end coordinated-disclosure timeline or an explicit confirmation that a specific core patch had shipped at the exact moment of publication — details the security community will reasonably want clarified, given that a pre-auth RCE affecting default WordPress installs on MySQL is not a finding that can circulate safely while unpatched. Readers should track official WordPress security advisories for the definitive patch status.

The broader implication for defenders is structural: if a $25 AI run can find a $500,000 bug in the world's most-audited open-source CMS, continuous AI-assisted code auditing needs to become a standard component of the secure development lifecycle for major open-source projects — not a research curiosity or an annual penetration test line item. The offensive capability is already deployed; the defensive adoption is lagging. As the competitive landscape for frontier AI models intensifies globally, this capability will likely get cheaper and more accessible over time, compressing the window for proactive defense with every new model release.

Key Takeaways

• Found WordPress RCEs in core, not plugins: The vulnerability chain affects a default WordPress installation via the REST Batch API (/wp-json/batch/v1) introduced in WordPress 5.6 — no plugins, themes, or unusual server configuration required.
• Two-bug chain: A Batch API index desynchronization (Bug 1) allows scalar input to reach an unescaped SQL sink in author__not_in (Bug 2), producing pre-auth SQL injection. That injection is then escalated to RCE via in-memory WP_Post cache poisoning combined with oEmbed cache persistence to the database.
• "GPT-5.6 Sol Ultra" did the work autonomously: Using up to 4 parallel agents, a minimum 6-hour runtime, and an anti-shortcut environment (no git history, no internet CVE lookup), the model identified and chained both bugs without human guidance on where to look.
• Total cost: ~$25: The researcher's estimate is roughly half a week's pro-rated usage of a $200/month OpenAI subscription — against a bug class that exploit brokers, per Kues's framing, pay up to $500,000 for, a four-to-five-orders-of-magnitude cost asymmetry.
• Standard hardening is ineffective: Hiding admin pages, customizing 404 not found and page not found responses, suppressing no posts found output, issuing 302 found redirects, or restricting file not found error verbosity has zero effect on a REST API-layer pre-auth vulnerability.
• The prompt is a reusable template: Adapted from a published OpenAI CDC conjecture prompt, the multi-agent orchestration methodology transfers directly to AI-assisted auditing of any large open-source codebase.
• Disclosure was partially coordinated: Kues prepared a report to send to WordPress and Searchlight Cyber delayed publication to let defenders upgrade over a weekend; Calif and Hacktron independently reproduced the chain in that window. A formal end-to-end disclosure timeline and explicit patch confirmation were not detailed in the post — worth monitoring via official WordPress security advisories.

What Comes Next

The immediate pressure falls on WordPress maintainers to patch the Batch API desync in class-wp-rest-server.php and close the author__not_in scalar input path in WP_Query — two relatively surgical fixes that shouldn't require breaking changes to the REST API contract. WordPress site administrators should monitor the official WordPress security releases feed and apply any core update addressing this chain immediately upon release, given the severity of pre-auth RCE exposure.

For developers and security teams managing WordPress deployments at scale, several interim mitigations are worth considering while awaiting a patch:

• WAF rules targeting the Batch API: Consider rate-limiting or requiring authentication for requests to /wp-json/batch/v1 at the web server or WAF layer if your application doesn't require unauthenticated batch API access.
• Database privilege reduction: Ensure the WordPress database user has only the minimum required privileges — no FILE privilege, no ability to write to the filesystem via MySQL — to limit RCE escalation vectors even if SQL injection is achieved.
• Log monitoring: Unusual or malformed requests to /wp-json/batch/v1 containing nested batch calls or scalar values in author_exclude parameters are detectable anomalies worth alerting on.

Longer term, the WordPress project and other major open-source platforms face a strategic question this research makes urgent: should automated AI auditing runs be a required gate in every major release cycle? The evidence here suggests yes, and that the cost of not doing so is denominated in high exploit-market prices and the exposure of hundreds of millions of websites. As the competitive landscape for frontier AI models intensifies globally, the capability demonstrated here is likely to become cheaper and more accessible over time — making the window for proactive, AI-assisted defense narrower with every release that ships without it.