TL;DR Two chained WordPress Core vulnerabilities (CVE-2026-63030 and CVE-2026-60137) give an unauthenticated attacker remote code execution on any internet-facing WordPress installation running versions 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1. Exploitation is active and widespread. Versions 6.8.5 and earlier do not contain this vulnerability chain. Patch to 6.9.5 or 7.0.2 immediately; if patching cannot happen right now, block anonymous access to /wp-json/batch/v1 at your edge as a temporary measure. Bitdefender MDR is actively monitoring for this threat and investigating affected customers.
| WordPress Version | Status |
| 6.8.5 and earlier | Not affected by this chain |
| 6.9.0 - 6.9.4 | Affected - update immediately |
| 6.9.5 and later (6.9 branch) | Fixed |
| 7.0.0 - 7.0.1 | Affected - update immediately |
| 7.0.2 and later (7.0 branch) | Fixed |
Two vulnerabilities in WordPress Core were publicly disclosed on 2026-07-17. CVE-2026-63030 is a flaw in WordPress’s REST API batch endpoint. CVE-2026-60137 is a SQL injection vulnerability in the post query layer. Their combined CVSS score of 9.8 out of 10 reflects a vulnerability that is remotely exploitable, requires no authentication, and demands no special configuration to trigger. Individually, neither produces code execution. Chained, they give an unauthenticated attacker full remote code execution on any affected WordPress installation.
CISA added both to its Known Exploited Vulnerabilities catalog (a maintained list of vulnerabilities confirmed to be actively exploited against real targets) on 2026-07-21, before a public exploit was available. A fully functional proof-of-concept exploit was published on 2026-07-22: Icex0, “wp2shell-poc”, July 2026, an independent implementation of the vulnerability chain discovered by Searchlight Cyber, “wp2shell: Pre Authentication RCE in WordPress Core”, July 2026. The PoC automates the complete initial-access chain in a single scripted run. Exploitation was already active before the PoC dropped; it has accelerated since.
WordPress.org pushed forced auto-updates to 6.9.5 and 7.0.2 for installations with automatic updates enabled. Widespread exploitation has been confirmed by Bitdefender MDR, which is monitoring the situation and actively investigating affected customers.
Attackers begin with a mass-scanning phase: automated probes against internet-facing WordPress installations, testing for the presence of the vulnerable batch endpoint. This phase is slow by campaign standards, detectable by any organization with network visibility, and not yet the moment of compromise. Attackers use that window to triage and prioritize targets from their scan results. Defenders who catch the scanning have hours before the fast, automated compromise starts.
When exploitation begins, the initial-access chain runs as a single scripted sequence. The public PoC desynchronizes the batch endpoint, performs the SQL injection, bridges to administrator account creation, and drops a webshell without any manual intervention between steps. That speed comes directly from the automation: the PoC removes every manual handoff from the initial-access phase. The scanning phase, still partly paced by human triage decisions, has not been automated the same way. It remains the durable early-warning signal precisely because it is the one phase where defenders can act before the clock starts.
Bitdefender MDR investigated a compromised server running a WordPress installation vulnerable to both CVEs. The incident produced an observation not present in any public reporting: the attack ran three times before it fully succeeded.
The first attempt executed the scripted chain, created an unauthorized WordPress administrator account with a w2s_ prefix, and stopped. No plugin was activated. No webshell was deployed. The second attempt produced the same outcome: a second w2s_-prefixed administrator account, another stall. The third attempt did not stop. It obtained administrator access, uploaded and activated multiple malicious plugin droppers (packages that silently install additional code onto a WordPress site without the site owner’s knowledge), deployed PHP webshells (scripts that accept commands over HTTP, giving an attacker remote control over the web server), and achieved remote code execution.
The reason partial attempts leave anything behind is structural. The scripted chain’s cleanup routine only runs on full success. When a compromise stalls partway, the rogue administrator account stays in place. An orphaned w2s_-prefixed account on a server with no visible webshell is a confirmation that the server was targeted, the chain ran at least partway, and the attacker may return.
For defenders, this reframes compromise assessment: you are not looking for a webshell as your first indicator. You are looking for an administrator account you did not create.
The full RCE chain requires WordPress 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1, internet-facing, without WAF (web application firewall, a security layer that inspects and filters HTTP traffic before it reaches the application) rules restricting anonymous access to the batch endpoint.
Two factors limit the blast radius. Fixed versions were available on the date the public PoC dropped. WordPress.org’s forced auto-updates have already patched many installations. Before treating every WordPress deployment as exposed, verify whether auto-update ran and applied successfully rather than assuming it did.
Two factors extend it. WordPress powers a substantial fraction of internet-facing web infrastructure. The public PoC makes this a low-skill attack: an attacker does not need to understand the vulnerability chain to run the exploit. CISA KEV confirmation preceded the public PoC, meaning organized threat actors had already operationalized this before less sophisticated attackers could access a ready-made tool.
This is a playbook case. Internet-facing RCE with a scripted public exploit and CISA KEV confirmation follows a pattern that prior campaigns have established: mass scanning leads to initial access, initial access leads to webshell persistence, dwell time enables hands-on-keyboard activity by human operators, and hands-on-keyboard access in prior internet-facing RCE campaigns has reliably led to ransomware deployment.
If you have confirmed exposure, skip ahead to What To Do.
The chain requires two separate flaws. Neither produces remote code execution alone.
CVE-2026-63030 is a validation flaw in WordPress’s REST API batch endpoint, reachable at /wp-json/batch/v1 and equivalently at /?rest_route=/batch/v1. The REST API (Representational State Transfer Application Programming Interface) is the interface WordPress uses to expose site functionality to external tools and integrations. The batch endpoint allows multiple API sub-requests to be combined into a single HTTP call. The flaw: when a sub-request path includes a triple-forward-slash (///) prefix, the validation step and the execution step read the path differently. Validation sees a path that passes its checks; execution dispatches the sub-request under an incorrect handler that bypasses method-level authentication requirements. The tell in your access logs is an HTTP 207 (Multi-Status) response from this endpoint.
CVE-2026-60137 is a SQL injection flaw reachable via the author__not_in parameter in WordPress’s post query layer. SQL injection is a technique where attacker-supplied input is inserted directly into a database query, allowing the attacker to extract or modify data the application did not intend to expose. The batch desync from CVE-2026-63030 delivers the attacker’s crafted sub-request to this parameter without triggering authentication checks, enabling a UNION-based extraction of data from the WordPress database (UNION-based refers to a specific technique that appends a second query to the attacker’s injected input, pulling data from tables the original query was never meant to touch).
From there, the scripted chain abuses two legitimate WordPress mechanisms as a bridge to administrator account creation. First, it writes attacker-controlled data into the site’s oEmbed cache. OEmbed is a standard protocol for generating embedded previews of linked content; WordPress stores these previews in the database. Second, it creates a customizer changeset, a staged and unapplied theme configuration record, also stored in the database. Together, these writes are used to insert a crafted value into the WordPress options table, resulting in a fully functional administrator account with a w2s_-prefixed username.
With administrator access, the chain continues by uploading a malicious plugin. WordPress plugins are PHP code packages that extend site functionality; an authenticated administrator can install them without any additional restrictions. The plugin deploys PHP webshells at randomized paths inside wp-content, protected by per-run token authentication. Variants observed publicly also include a minimal one-liner shell returning HTTP 404 responses to avoid appearing in routine server logs, and custom REST API backdoors accepting base64-encoded commands (base64 is a standard encoding scheme that converts binary data to plain text for transmission, often used to obscure attacker commands from simple pattern inspection).
The w2s_ account prefix and the fun- and fun-proof- path segments are artifacts of the public PoC’s default configuration, trivially changed by any attacker who edits the tool. The durable indicators are behavioral: an administrator account that appeared without authorized action, an unknown plugin in wp-content/plugins/, a PHP file at a randomized path inside a wp-content/ subdirectory, and the network signature of nested batch requests with triple-slash paths returning HTTP 207 responses from the batch endpoint.
The steps below expand on the immediate actions summarized in the TL;DR.
Check your WordPress inventory against the affected versions: 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Any internet-facing installation in that range without WAF rules restricting anonymous access to /wp-json/batch/v1 should be treated as exposed. If auto-update was enabled, verify that it ran and applied successfully rather than assuming it did.
If you are unsure what WordPress versions you are running on internet-facing infrastructure, that gap is part of what this attack exploits. The scanning phase is the warning window. You can only act in it if you already know what you have exposed.
Update to WordPress 6.9.5 or 7.0.2.
If immediate patching is not possible, configure your WAF or edge layer to block or restrict anonymous (unauthenticated) HTTP requests to /wp-json/batch/v1. This closes the initial-access vector while patching is arranged. It is a temporary measure, not a substitute for patching.
Check your WordPress administrator user list for accounts with the w2s_ prefix that you did not create. As the MDR incident shows, the scripted chain creates that account on every attempt, successful or not. An orphaned rogue administrator account with no accompanying webshell is not a false alarm. If you find one, the server was targeted; treat the installation as potentially compromised and investigate further.
Look for the following regardless of whether the PoC-default naming is present:
For SHA-256 hashes of the webshells and plugin droppers observed in the Bitdefender MDR investigation, see the Indicators of Compromise section below.
The following network indicators remain durable across attacker tool variations:
Any WordPress administrator account that appears without a corresponding authorized action is a high-fidelity indicator regardless of whether the w2s_ prefix is present.
The following indicators come from Bitdefender MDR’s investigation of an active wp2shell compromise. SHA-256 file hashes are the reliable anchors for the specific samples observed. Naming-pattern-based indicators (w2s_, fun-, fun-proof-) are public PoC defaults and may differ across campaigns; treat them as supporting signals, not sole detection criteria.
Source IPs observed in active exploitation:
|
80.82.65[.]226 |
Unauthorized WordPress administrator accounts:
|
w2s_f73988c90f56 |
The w2s_ prefix is a PoC default. Any unknown administrator account warrants investigation regardless of prefix.
PHP webshells (paths anonymized to <wordpress-root>) with SHA-256:
|
<wordpress-root>/wp-content/fun-f17823f5523d3b6efaea5883f051de573985ae385c1a8d4d/545d84a8978270eb53fe34f9a5cedb1669b5d1be5d1f90de.php |
Malicious plugin droppers with SHA-256:
| <wordpress-root>/wp-content/plugins/fun-proof-0ba7bc912b8b/fun-proof-0ba7bc912b8b.php 37d86716edcb5b481d5d34b38b3bb4b522fcabdf0baf9b0523a0a61957620fad <wordpress-root>/wp-content/plugins/fun-proof-84852efbb4f2/fun-proof-84852efbb4f2.php 4f4dc354dfa3ab9df33107b02106424d9940119363ceaff3399aefa8b14859dc <wordpress-root>/wp-content/plugins/fun-proof-c56069883a8c/fun-proof-c56069883a8c.php 67ce5c125611078c2a6294faacd378b7dccbfb490641a0ca0822b071a22f759c <wordpress-root>/wp-content/plugins/fun-proof-cf4f785b2b9f/fun-proof-cf4f785b2b9f.php ee8395666b9367967749757da27784922fdc18dc3e85db864d30fa703eb9db18 <wordpress-root>/wp-content/plugins/fun-proof-d92f9c1999e4/fun-proof-d92f9c1999e4.php 12de8ce21bc534a968c327c00f2aa933b9034bc39b367ad1659f5aaa8be07744 |
The fun- and fun-proof- path segments are PoC defaults. In your environment, look for unknown plugin directories and unknown PHP files at randomized paths inside wp-content/, regardless of naming pattern.
Behavioral and network signatures (durable across tool variations):
Bitdefender Managed Detection and Response (MDR) provides 24/7 threat monitoring and active investigation by Bitdefender analysts. MDR is actively hunting for wp2shell activity across the customer base and investigated the three-attempt compromise documented in this advisory.
The speed of MDR’s response to any new threat depends partly on knowing what software customers are running. When MDR’s records show a customer is running an affected WordPress version, tippers and scope assessments go out before the compromise is already underway. When MDR has to dynamically discover who may be vulnerable, response is slower. Keeping your software inventory current in GravityZone is the customer’s half of that arrangement. Against an attack that moves from exploit to administrator access in roughly two minutes once it starts, the advance inventory record is what makes proactive notification possible in time to matter.
This attack runs on a timeline that makes external attack surface management (EASM) directly relevant. EASM continuously monitors your internet-facing assets from outside your perimeter, without requiring an agent on any device. The multi-hour gap between mass scanning and active exploitation is only a usable window if you already know which of your internet-facing systems run WordPress and which are on vulnerable versions. EASM provides that inventory before the scanning starts, so the warning window is actually actionable rather than time that passed while you were unaware.
EASM is distinct from Risk Management: EASM works externally and agentlessly, discovering exposed infrastructure from outside your perimeter. GravityZone Risk Management works internally, using a deployed agent on managed endpoints.
For managed endpoints, GravityZone Risk Management identifies unpatched software versions through agent-based scanning, providing visibility into which WordPress installations on GravityZone-managed machines are running affected versions. It covers machines where a GravityZone agent is deployed; it does not cover externally hosted or unmanaged infrastructure.