WordPress wp2shell is an unauthenticated remote-code-execution chain in WordPress core — requiring no plugins, no login, and no special configuration — that was discovered by an AI model in 10 hours and patched on July 17, 2026. If you run any WordPress site on versions 6.9 through 7.0.1, your site can be fully taken over by a single HTTP request. You need to update to WordPress 7.0.2 (or 6.9.5, or 6.8.6) right now. WordPress has enabled forced automatic updates for affected sites, but you should verify yours manually — over 11 million attack attempts were already blocked by Wordfence alone within days of disclosure [^1].
Last verified: 2026-07-31 · CVE: CVE-2026-63030 (CVSS 9.8 Critical) + CVE-2026-60137 (CVSS 7.5 High) · Affected: WordPress 6.9–6.9.4 and 7.0–7.0.1 (SQLi present from 6.8) · Fixed in: 7.0.2, 6.9.5, 6.8.6 · Named: wp2shell · Discovered by: Adam Kues, Searchlight Cyber, using GPT-5.6 Sol Ultra
What is WordPress wp2shell (CVE-2026-63030)?
WordPress wp2shell is a two-vulnerability chain in WordPress core that lets an unauthenticated attacker create an administrator account and then execute arbitrary code on the server — all through standard WordPress REST API endpoints that exist on every default installation. The name follows the "-shell" convention (like Log4Shell) because it turns a complex logic flaw into a remote shell [^2].
The chain combines two bugs:
| # | CVE | Type | CVSS | What it does | Fixed in |
|---|---|---|---|---|---|
| 1 | CVE-2026-60137 | SQL Injection in WP_Query (author__not_in) |
7.5 (High) | Lets an attacker inject raw SQL into the database query layer via the author__not_in parameter, which is not properly sanitized when it arrives as a string instead of an array |
6.8.6, 6.9.5, 7.0.2 |
| 2 | CVE-2026-63030 | REST API batch-route confusion | 9.8 (Critical) | Desynchronizes validation from execution in the REST API batch endpoint, allowing a validated request to be dispatched to an unintended handler with unsanitized parameters — turning the SQLi above into an unauthenticated, remotely reachable attack | 6.9.5, 7.0.2 |
Neither bug alone is enough. The REST API normally sanitizes the author_exclude parameter as an array of integers before it reaches WP_Query, and the batch endpoint normally rejects unvalidated sub-requests. Chaining the two — a "double confusion" — bypasses both defences and reaches the SQL injection without any authentication [^3].
How does the wp2shell attack chain work?
The attack works in five exploitation steps followed by a normal plugin upload, exploiting a stock WordPress installation:
Route desync via a poisoned batch request. An attacker sends a single POST to
/wp-json/batch/v1with a first sub-request whose path ishttp://— a deliberately invalid URL that failswp_parse_url()and becomes aparse_path_failederror. This error stays in the$requestsarray at index 0 but is never added to the$matchesarray. Every subsequent handler lookup is now shifted by one index [^3].Method bypass. Because the parent request was correctly validated as a POST, the desynchronized sub-request at index 1 (originally a GET) gets dispatched using the POST handler's validation — bypassing the batch endpoint's allow-list that normally only permits POST, PUT, PATCH, and DELETE sub-requests [^4].
SQL injection via
author__not_in. The mis-dispatched GET request targets the posts endpoint with anauthor_excludeparameter. Because validation was skipped by the desync, this string value reachesWP_Query'sauthor__not_inhandling without thearray_map('absint', ...)sanitization that normally runs only when the value is an array. The raw string is cast to a single-element array, imploded, and concatenated directly into the SQLWHEREclause [^3].Admin account creation. Through the SQL injection, the attacker extracts or manipulates database records — ultimately creating a new WordPress administrator account by posting to the
v2/usersendpoint with the bypassed validation [^4].Plugin upload (normal WordPress behaviour). With admin access, the attacker uploads a malicious plugin (a "web shell") that provides full filesystem access. The attacker then deletes the new admin account to cover tracks [^4].
The entire chain requires no authentication, no plugins, and works against the default WordPress configuration. Cloudflare noted that the RCE path requires persistent object cache to be disabled — a common default for small and mid-size WordPress sites [^5].
Which WordPress versions are affected by wp2shell?
This is the complete affected-versions map, verified against the GitHub security advisory and the WordPress 7.0.2 release notes:
| WordPress branch | Affected versions | Vulnerable to | Fix version |
|---|---|---|---|
| 7.0.x | 7.0, 7.0.1 | Both SQLi + route confusion (RCE) | 7.0.2 |
| 6.9.x | 6.9, 6.9.1, 6.9.2, 6.9.3, 6.9.4 | Both SQLi + route confusion (RCE) | 6.9.5 |
| 6.8.x | 6.8 through 6.8.5 | SQLi only (no route confusion — RCE not reachable) | 6.8.6 |
| <= 6.7.x | Not affected | — | Stay current |
The route confusion (CVE-2026-63030) was only introduced in WordPress 6.9 — the batch endpoint code path that enables the desync did not exist in earlier versions. The SQL injection (CVE-2026-60137) reaches back to 6.8 but is not remotely exploitable without the route confusion to feed it unsanitized input [^3][^6].
How was wp2shell discovered? An AI found it in 10 hours
Here is the part that should worry every software team building with AI: the entire exploit chain was discovered by GPT-5.6 Sol Ultra — OpenAI's frontier reasoning model — not by a human security researcher's manual code audit.
Adam Kues, a security researcher at Searchlight Cyber (Assetnote), tasked GPT-5.6 Sol with finding a pre-authentication-to-RCE vulnerability chain in WordPress core, using a maximum of four AI agents and a minimum of six hours of compute. The model found a read-only SQL injection within minutes, escalated it to full remote code execution in just over 10 hours, and estimated the total token cost at around $25 [^7][^8].
Kues stated: "No security researcher could have found and completed this exploit chain in 10 hours without AI." The model identified the author__not_in SQL injection, the batch endpoint route confusion, a cache-poisoning technique via oEmbed, a customize_changeset privilege escalation, and a cycle-detection gadget that re-triggered the parse_request hook [^7]. The same exploit, if sold to exploit brokers, could have fetched roughly $500,000 [^8].
The Searchlight Cyber researchers did not jailbreak the model. They adapted a prompt that OpenAI had previously published for solving math problems and applied it to the WordPress source code. WordPress — as Kues noted — is "one of the most hardened targets of all time," and had not had a meaningful pre-auth vulnerability this decade before this find [^8].
What this means for the AI-security arms race
If a $25 AI run can find a critical zero-day in one of the world's most audited codebases, two things change simultaneously: defenders must patch faster (WordPress shipped a forced auto-update within hours), and attackers can scan-and-exploit at machine speed. Wordfence's telemetry confirms this is already happening — over 11 million exploit attempts were blocked by their firewall alone by July 29, 2026 [^1]. If you are building AI tools, read our deeper analysis of Anthropic's Claude cybersecurity evaluation incident, where three real systems were breached during AI security testing, and our framework for multi-user AI agent security and memory privacy — the same attack-surface questions apply here.
How to check if your WordPress site is vulnerable or already hacked
Follow these steps in order. Do not skip the post-hack audit even if you have already updated — attackers may have already created rogue admin accounts before the patch landed.
- Check your WordPress version. Log in to your dashboard and look at the bottom-right of any admin screen, or run
wp core versionif you have WP-CLI. If it is 6.9.x through 6.9.4, or 7.0 through 7.0.1, you are vulnerable. - Check if the vulnerability is exploitable on your install. According to Cloudflare, the RCE path requires persistent object cache to be disabled. If you use a persistent object cache (Redis, Memcached), the RCE may not be reachable — but the SQL injection still is. Update regardless [^5].
- Audit your admin users. Go to Users → All Users in the WordPress admin. Look for any admin account you did not create, especially with usernames like
已然, random strings, or generic names. A common wp2shell attack creates an admin, uploads a web shell plugin, then deletes the admin to hide the trail — so also check for recently deleted users in your database'swp_userstable. - Check your plugins directory. Look in
/wp-content/plugins/for any plugin folder you did not install. Attackers typically upload a "web shell" plugin disguised with an innocuous name. - Review your access logs. Search for requests to
/?rest_route=/batch/v1or/wp-json/batch/v1in the days following July 17, 2026. A large volume of POST requests to this endpoint is a strong indicator of exploitation attempts [^9]. - Scan with a security plugin. Wordfence, Sucuri, or Patchstack can detect known web shell signatures and suspicious admin accounts.
How to fix wp2shell and protect your WordPress site
The fix is simple — update WordPress core. The hardening steps below reduce future risk.
Immediate fix: update WordPress core
| Your version | Update to | Both bugs fixed? |
|---|---|---|
| 7.0 or 7.0.1 | 7.0.2 | Yes |
| 6.9 through 6.9.4 | 6.9.5 | Yes |
| 6.8 through 6.8.5 | 6.8.6 | SQLi only (route confusion not present) |
WordPress has enabled forced automatic updates for sites running affected versions, so your site may have already patched itself. Verify manually via Dashboard → Updates. If you manage updates only on weekends (as one Reddit user reported their site being compromised two days after disclosure [^4]), change that policy today — critical security releases require same-day patching [^6].
Hardening steps after the fix
- Enable persistent object cache. Cloudflare confirmed the RCE path requires persistent object cache to be disabled. Using Redis or Memcached as your object cache back-end closes the RCE vector even if a similar bug reappears [^5].
- Deploy a WAF rule. Wordfence Premium, Patchstack RapidMitigate, and Cloudflare all shipped firewall rules for CVE-2026-63030 on July 17, 2026 — the same day as disclosure. Wordfence's free tier receives the rule 30 days later (August 16, 2026) [^1].
- Review admin user lists weekly. The wp2shell chain creates a rogue admin as its final step. Catching unknown admins early limits damage.
- Restrict plugin installation. If you do not need the admin plugin-upload functionality on a given site, restrict it via
define('DISALLOW_FILE_MODS', true);inwp-config.php. This prevents the final RCE step (malicious plugin upload) from working even if an attacker gets admin credentials. - Check CISA KEV. Both CVEs were added to CISA's Known Exploited Vulnerabilities catalog on July 21, 2026, confirming active exploitation. If you operate in a regulated environment or for the US federal government, patching is mandatory [^5].
How does wp2shell compare to past WordPress vulnerabilities?
WordPress has had serious vulnerabilities before, but wp2shell is distinct in three ways:
| Dimension | wp2shell (2026) | Typical WP plugin vulns | Past core vulns |
|---|---|---|---|
| Location | WordPress core (no plugin needed) | Third-party plugins | Core, but usually authenticated or requiring specific config |
| Auth required | None (unauthenticated) | Usually authenticated (subscriber+) | Variable |
| Preconditions | Stock install, no plugins, no config | Specific plugin installed | Specific configuration or user role |
| Discovery | AI (GPT-5.6 Sol, 10 hours, $25) | Manual research or scanning | Manual research |
| Exploitation speed | Mass-exploited same day as disclosure | Typically slower | Variable |
Most WordPress vulnerabilities historically reside in third-party plugins [^5]. wp2shell is significant because it lives entirely in core, the base application maintained by the WordPress project. It is exploitable by an unauthenticated user against a default installation that requires no plugins and no special configuration. This makes it one of the few critical unauthenticated WordPress core RCEs in nearly a decade [^1].
What this means for you
If you run a WordPress site (or build for clients who do): Treat this as the highest-priority patch of 2026. WordPress powers roughly 41.2% of all websites — over 260 million sites — so this vulnerability affected a staggering number of properties [^10]. Even with forced auto-updates, verify your version, audit for rogue admins, and enable persistent object cache as a defence-in-depth measure.
If you build AI tools: The fact that a $25 AI run found a critical zero-day in WordPress core — a target Kues calls "one of the most hardened of all time" — is a watershed moment for vulnerability research. If you are building AI agents that interact with code, see our analysis of why AI coding tools are not always making developers faster and the implications of GPT-5.6 Sol as a frontier reasoning model. The same model that writes your code can now find the holes in someone else's.
If you run infrastructure that stores user data on WordPress: Recall that data breaches have real-world consequences. Our analysis of the DRDO data breach on the dark web walks through what happens when a breach listing surfaces and the gap between disclosure and damage control. wp2shell could have been the vector for similar incidents if the patch had been slower.
FAQ
Q: What is WordPress wp2shell? A: wp2shell is a critical vulnerability chain in WordPress core (CVE-2026-63030 + CVE-2026-60137) that lets unauthenticated attackers create an admin account and execute arbitrary code on the server via the REST API batch endpoint. It requires no plugins and works on a default WordPress installation. It was patched in WordPress 7.0.2, 6.9.5, and 6.8.6 on July 17, 2026.
Q: Is my WordPress site vulnerable to wp2shell? A: Your site is vulnerable if it runs WordPress 6.9 through 6.9.4, or 7.0 through 7.0.1. The SQL injection portion (CVE-2026-60137) also affects 6.8 through 6.8.5, but the full RCE chain requires the route confusion bug that was only introduced in version 6.9. WordPress has enabled forced automatic updates, but you should verify your version manually.
Q: How does the wp2shell attack work?
A: An attacker sends a crafted batch request to /wp-json/batch/v1 containing a deliberately malformed sub-request that desynchronizes the validation and execution arrays. This causes a subsequent sub-request to bypass parameter sanitization, allowing a raw string to reach the author__not_in SQL query parameter without escaping. The attacker uses the resulting SQL injection to create an administrator account, then uploads a malicious plugin for full server access — all without authentication.
Q: Was wp2shell discovered by AI? A: Yes. Security researcher Adam Kues at Searchlight Cyber used OpenAI's GPT-5.6 Sol Ultra model to discover and build the full exploit chain in approximately 10 hours, at a cost of about $25 in tokens. The model was not jailbroken — it was given a standard prompt adapted from an OpenAI math-reasoning template. Kues stated no human researcher could have completed this chain in 10 hours without AI assistance.
Q: How many WordPress sites were attacked? A: Wordfence reported blocking over 11 million exploit attempts targeting CVE-2026-63030 by July 29, 2026, with mass exploitation beginning July 18 — the day after disclosure. Both CVEs were added to CISA's Known Exploited Vulnerabilities catalog on July 21, 2026, confirming active exploitation. The exact number of compromised sites is not publicly known, but forced automatic updates limited the exposure window.
Q: How do I fix wp2shell? A: Update WordPress to 7.0.2, 6.9.5, or 6.8.6 depending on your branch. WordPress has enabled forced automatic updates for affected sites. After updating, enable a persistent object cache (Redis or Memcached) — Cloudflare confirmed this blocks the RCE vector. Audit your admin users for any account you did not create, check your plugins directory for unknown uploads, and deploy a WAF rule from Wordfence, Patchstack, or Cloudflare.
Discussion
0 comments