wp2shell WordPress Vulnerability (CVE-2026-63030): Pre-Auth RCE, Affected Versions, and How to Patch

What is wp2shell?

Most WordPress incidents we get called about start with an abandoned plugin. This one does not. wp2shell is a vulnerability in WordPress Core itself, which means a default, fully "clean" install with no third-party code was exploitable the moment it was exposed to the internet. That is what makes it the most serious WordPress vulnerability of 2026 so far.

The entry point is the REST batch endpoint — /wp-json/batch/v1, or /?rest_route=/batch/v1 on sites without pretty permalinks. That endpoint exists so a client can bundle several REST calls into one request. Searchlight Cyber found that when sub-requests inside a batch call get out of sync, a request can be dispatched under the wrong REST handler. Public chains nest batches to bypass HTTP method restrictions and then reach a pre-authentication SQL injection primitive through query parameters that should never have applied on the route they landed on.

"Pre-authentication" is the phrase that should move this to the top of your queue. No login, no subscriber account, no nonce. Anyone who can reach your site over HTTP can reach the vulnerable code path. The activity maps to MITRE ATT&CK T1190 (Exploit Public-Facing Application), T1505.003 (Web Shell), and T1059 (Command and Scripting Interpreter).

Which WordPress versions are affected?

Two branches carry the full RCE chain, and one older branch carries the SQL injection half of it. Per the published advisories:

Two practical notes. First, "not affected by the full chain" is not the same as "safe" — older releases are missing months of unrelated security fixes and should be updated anyway. Second, check the version you are actually running, not the one you think you deployed. On managed hosting and in container images the running version is frequently pinned behind what the dashboard implies.

How the exploit chain works

At a high level — no payloads, because working exploit code is already public and does not need our help — the chain runs like this:

1. Route confusion. Nested batch sub-requests desynchronise, and a request is dispatched under a REST handler it should never have reached.
2. Pre-auth SQL injection. Query parameters that are not valid for the landing route are still processed, exposing an unauthenticated SQLi primitive.
3. Escalation. Tooling diverges here. The most widely circulated proof of concept bridges the SQLi into an administrator session and then uploads a plugin ZIP; other actors skip that and write PHP directly to disk using SQL INTO OUTFILE.
4. Code execution. Either route ends with attacker-controlled PHP on the host, executed by the web stack — a webshell running as www-data or equivalent.

Elastic Security Labs ran the public chain end to end in a lab and describes a very consistent host footprint: the web server process writes temp-write-test-* probe files under wp-content/ to confirm the directory is writable, stages a ZIP under wp-content/uploads/, unpacks PHP under wp-content/upgrade/, and finally renames a directory into wp-content/plugins/wp2shell_<hex>/. Then apache2 spawns dash and runs discovery commands — id, whoami, hostname. Notably, the public tooling also deletes its own plugin directory after execution, so a missing wp2shell_* folder is not evidence that a host is clean.

Am I compromised? Indicators to hunt

These indicators come from Elastic Security Labs' lab run and telemetry, plus the in-the-wild payloads captured by SANS ISC. Treat them as fragile: an attacker who renames the plugin slug or changes the User-Agent erases most of them in one edit. Hunt them now while stock tooling is still dominant, and rely on behavioural detection afterwards.

Web and access log indicators

• POST /?rest_route=/batch/v1 or POST /wp-json/batch/v1 carrying a nested JSON requests array.
• User-Agent strings wp2shell, cve-2026-63030/1.0, or rezwp2shell on batch traffic.
• HTTP 207 Multi-Status responses on batch requests — supporting evidence, not proof on its own.
• Follow-on requests to /wp-admin/plugin-install.php, /wp-admin/update.php?action=upload-plugin, or /wp-json/wp/v2/users?context=edit.

Host and filesystem artifacts

• Directories matching wp2shell_<hex> under wp-content/plugins/.
• New or modified .php files under wp-content/plugins/ or wp-content/cache/.
• temp-write-test-* files under wp-content/.
• Unexpected WordPress administrator accounts created during the exploitation window.
• Process lineage where a web server — apache2, httpd, nginx, or php-fpm — is the parent of a shell (sh, dash, bash). This is the durable signal; a web server should almost never spawn an interactive shell on a production host.

How to patch WordPress now

Patch first, investigate second. A compromised host that is still vulnerable will simply be reinfected while you triage.

• Dashboard: Dashboard > Updates, then apply the core update. Sites with core auto-updates enabled for minor releases may already be on the fixed version — verify rather than assume.
• WP-CLI: wp core update --version=7.0.2 (or 6.9.5 / 6.8.6), then wp core update-db and confirm with wp core version.
• Managed hosting: check your host's status page — several large hosts push emergency core patches and edge rules for Core RCEs. You still own verification.
• Containers: rebuild against a fixed wordpress: image tag and redeploy. Updating in a running container is lost on the next deploy.
• Every install, not just the main one: staging copies, multisite networks, forgotten subdomains, and old client sites on the same shared account are all entry points into the same filesystem.

If you were exploited: cleanup checklist

If any of the indicators above match, or if the site was internet-facing and unpatched for a meaningful window, work the incident rather than just deleting a folder. Code execution as the web user means everything that user could read is suspect.

• Isolate and snapshot the host before you clean it — you will want the evidence later.
• Audit administrator accounts and application passwords; delete anything created during the window.
• Rotate secrets: WordPress salts and keys in wp-config.php, the database user's password, SMTP and payment API keys, and any credentials stored in plugin settings.
• Restore Core, plugins, and themes from clean sources rather than attempting to diff a live tree by hand. Compare wp-content/ against a known-good backup for injected PHP.
• Check for persistence outside WordPress: cron jobs, SSH authorized_keys, systemd units, and modified .htaccess files.
• Assess your TLS private key. If the key file lives on this host and is readable by the web server user, treat it as compromised: generate a new key and a fresh CSR, reissue the certificate, and revoke the old one. Our private key guide and revocation guide cover the process.

Mitigations if you can't patch yet

There are legitimate reasons a core update has to wait a few hours — a frozen release window, a heavily customised build, a client who has to approve it. In that gap:

• Block anonymous access to the batch endpoint — /wp-json/batch/v1 and /?rest_route=/batch/v1 — at your CDN, WAF, or web server config. Expect legitimate batch consumers to break; this is temporary.
• Disable anonymous REST access with a hardening plugin if your site does not need a public REST API.
• Enable managed WAF rules. Cloudflare, Sucuri, Wordfence, and the major hosts shipped virtual patches for this CVE quickly. Virtual patching buys time; it is not a substitute for the update.
• Make wp-content/plugins/ non-writable by the web user where your workflow allows it. It breaks dashboard plugin installs — and it also breaks the plugin-upload half of this chain.

Does HTTPS or an SSL certificate protect you?

No — and this is worth saying plainly, because "we have an SSL certificate, we're secure" is still one of the most common misconceptions we hear. TLS protects data in transit: it stops interception and tampering between the browser and your server. It does not read, validate, or filter what the request contains. A wp2shell exploit request rides inside the encrypted channel exactly like a legitimate one. If anything, TLS makes it slightly harder for network-level inspection tools to see the attack — which is why detection has to happen at the application, log, and host layers.

HTTPS remains non-negotiable for confidentiality, integrity, and browser trust. It is just a different control from application patching. If you want the model behind that, see how SSL/TLS actually works and SSL vs TLS vs HTTPS. For keeping your certificate estate healthy — including after an incident forces a rekey — see our certificate management guide and the WordPress SSL installation guide.

Timeline and disclosure

• 17 July 2026 — Searchlight Cyber publicly discloses wp2shell, covering CVE-2026-63030 and CVE-2026-60137, alongside a write-up of how the bug was found. Proof-of-concept tools appear on GitHub within hours.
• Days following — SANS Internet Storm Center reports active exploitation in the wild and captures live SQL injection payloads.
• 22 July 2026 — Elastic Security Labs publishes a defender-facing analysis: an end-to-end lab reproduction, host telemetry, detection rules, and the IOC set summarised above.

Always confirm version numbers and CVE detail against the primary advisories linked in the sources below before you commit them to a ticket or a customer notification.

FAQ