WordPress: wp2shell Chain Exploited in the Wild 24 Hours After…

The wp2shell vulnerability chain in WordPress Core was discovered using AI for roughly $25, published July 17, and actively exploited in cloud environments within 24 hours.

On July 17, 2026, a critical vulnerability chain in WordPress Core — dubbed wp2shell and comprising CVE-2026-63030 and CVE-2026-60137 — went from AI-assisted discovery to active exploitation in the cloud in under 24 hours. Wiz Research documented successful attacks against self-hosted instances almost immediately after publication, with deployment of sophisticated webshells and ongoing post-exploitation activity. WordPress.org responded by enabling forced auto-updates, an unprecedented measure reflecting the severity of the case.

Key Takeaways

The wp2shell chain exploits an architectural flaw in WordPress REST API batch parameter validation, enabling route confusion that bypasses sanitization and leads to pre-authentication SQL injection scalable to RCE.
Wiz Research observed successful exploitation "almost immediately" after the July 17 publication, with deployment of malicious plugins, a 150KB webshell disguised as CMSmap, user enumeration, and LFI attempts for database credentials.
At publication time, 60% of organizations in the Wiz dataset had at least one vulnerable instance and 25% exposed a vulnerable server to the internet; within 24 hours those figures dropped to 50% and 10%, indicating rapid patching but equally rapid exploitation.
WordPress.org activated forced auto-updates for affected versions (6.8.0-6.8.5, 6.9.0-6.9.4, 7.0.0-7.0.1) with fixes in 6.8.6, 6.9.5, and 7.0.2, labeling the security release as one to apply "immediately."

How the Attack Works: Architectural Flaw in the Batch API

The technical core of the wp2shell chain lies in WordPress REST API batch processing. Parameter validation — the has_valid_params function — is decoupled from execution of the callback associated with the route. This misalignment enables route confusion: an attacker can route a request to an endpoint that passes the validation check, but the executed callback belongs to a different route with higher privileges or access to unintended functionality.

The exploitation vector observed by Wiz Research abuses the /?rest_route=/batch/v1 endpoint. The batch API is designed to bundle multiple REST requests into a single call, but the missing correlation between validation and execution allows injection of malformed parameters that evade standard sanitization. The resulting pre-authentication SQL injection is then escalated to RCE without password cracking, leveraging the ability to execute code through the privileged context of the confused callback.

According to official WordPress.org release notes, the vulnerability is rated critical for the first CVE and high for the second, with documented RCE impact. The source does not specify the exact numerical CVSS, but the severity aligns with a pre-authentication vector, complete impact (confidentiality, integrity, availability), and ease of network access without user interaction.

What Wiz Observed in the Cloud: Two Attack Families

Wiz Research identified two distinct exploitation profiles, both active by July 17–18, 2026. The first is opportunistic mass scanning: high-volume requests to batch endpoints with no subsequent post-exploitation activity, typical of automated reconnaissance campaigns. A specific IP, 172.235.128[.]52, was associated with this mass-scanning pattern.

The second profile is targeted exploitation with persistent backdoor installation. Here Wiz documented at least three malicious artifacts. The first is a minimal PHP webshell, a one-liner with evasion based on an HTTP 404 response that hides the presence of remote access. The second is a 150KB attack platform disguised as a plugin named "CMSmap," featuring a GUI, password authentication, file management, database access, port scanning, batch code injection, and privilege escalation via MySQL UDF. Obfuscation employs hex-encoded concatenation, gzip, base64, and eval. The third artifact registers a custom REST API endpoint (/morning/v1/[REDACTED]) for command execution via POST with JSON output, indicating adaptation to the WordPress infrastructure itself.

Documented post-exploitation activities include: malicious plugin uploads for persistence, user enumeration via REST API, LFI (Local File Inclusion) attempts to extract database credentials, and administrative panel access. Wiz Research explicitly states it has not yet identified lateral movement or data exfiltration, while continuing monitoring.

The Speed of the Cycle: From $25 to Global Exploitation in a Day

The vulnerability was discovered by Searchlight Cyber using OpenAI GPT 5.6 Sol Ultra, at an estimated cost of roughly $25 — corresponding to 50% of a $200 weekly subscription. Researcher Adam Kues commented that "the post-exploitation work Sol had done to escalate this to RCE was completely absurd," referring to the model's ability to generate the full chain through to remote code execution.

The element that rewrites the risk parameters is not the AI discovery itself, but the temporal collapse of the discovery-to-exploitation cycle. The vulnerability was published with a PoC on July 17; within that same day and the next, Wiz detected active exploitation, WordPress.org released patches, and the exposure rate dropped 10 percentage points for vulnerable instances and 15 points for internet-exposed ones. The classic responsible disclosure model — 72-96 hours vendor notice, weekend buffer for patching before publication — proved inadequate for a tempo where weaponization is instantaneous.

The exposure percentages, however, carry an interpretive limit: the dossier does not clarify whether the 60%/25% and 50%/10% figures refer to Wiz's customer dataset or global estimates of the WordPress installed base. The phrasing "60% of WordPress organizations" in the Wiz text suggests a likely reference to its own dataset, but does not rule out broader projections.

Why It Matters

The dossier does not specify remedial measures beyond the two indicated by Wiz Research: block the /wp-json/batch/v1 endpoint at the WAF level, or disable anonymous access to REST APIs. The brief does not document further operational actions, nor detail whether these temporary mitigations apply to all architectures or have side effects on legitimate functionality. The source does not indicate specific verification procedures for already-installed backdoors, nor automated removal methods for the observed webshells.

It is not confirmed whether exploitation began before the July 17, 2026 publication. Wiz uses the formulation "almost immediately following the vulnerability chain's publication," which leaves open the theoretical possibility of pre-disclosure zero-day exploitation, but does not document it as fact. The identity of threat actors is undetermined: the dossier does not distinguish between nation-state, organized crime, or opportunistic operators, and the overlap between mass scanning and targeted deployment suggests multiple actors with varying sophistication levels.

The wp2shell case constitutes the first documented instance of a critical zero-day vulnerability discovered via generative AI and massively exploited in the wild within 24 hours, with a vendor response that includes forced auto-updates. For the security industry, the relevant datum is not the discovery tool but the structural obsolescence of reaction times: emergency patching and attack-surface control must now compete with a cycle that measures the discovery-to-exploitation interval in hours, not days.

"Multiple actors successfully exploiting this vulnerability chain against WordPress instances self-hosted in the cloud" — Wiz Research, July 17, 2026

FAQ

Which WordPress versions are actually at risk?

According to Wiz Research and the WordPress.org advisory, affected versions are 6.8.0-6.8.5, 6.9.0-6.9.4, and 7.0.0-7.0.1. The fix is available in 6.8.6, 6.9.5, and 7.0.2. Versions prior to the 6.8 branch are not affected by the wp2shell chain.

What do the IoCs indicate for detection?

Wiz Research identified high-fidelity indicators: HTTP 207/200 Multi-Status responses to requests against the batch endpoint, and user agents containing the strings "wp2shell" and "rezwp2shell." The source does not specify whether these patterns are sufficient to discriminate malicious activity from legitimate testing.

Is the CMSmap webshell linked to the legitimate repository?

The dossier does not confirm a link. The CMSmap GitHub repository (Source 3) is a legitimate Python scanner; the name was likely used as typosquatting or masquerade for the malicious webshell, but this reconstruction is not verified in the brief.

Sources

Information is based on the cited source and current as of publication.

Sources

Sources and references