Skip to content

WordPress wp2shell CVE-2026-63030 / CVE-2026-60137 exploitation

Summary

wp2shell is a pre-authentication remote-code-execution chain in WordPress Core. CVE-2026-63030 is a REST API batch-route interpretation-conflict issue that can expose the CVE-2026-60137 WP_Query author__not_in SQL-injection primitive on default installations. The combined chain affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1; WordPress 6.8.0 through 6.8.5 is affected by CVE-2026-60137 but not the default-install RCE chain described in CVE-2026-63030.

Wiz Research reported active exploitation on 2026-07-20 against self-hosted cloud instances. Observed activity included malicious-plugin and PHP-webshell installation, administrator-panel access, user enumeration, local-file-inclusion attempts against wp-config, and high-volume scanning. This moves wp2shell from patch prioritization into incident-response territory for internet-facing systems exposed before remediation.

Tags

Why this matters

  • The combined chain is remotely reachable without authentication on affected default WordPress installations and has a CVSS 3.1 base score of 9.8 in the CNA CVE record.
  • Wiz observed successful exploitation shortly after public disclosure, not only scanning or proof-of-concept traffic.
  • watchTowr subsequently reported internet-wide spraying after public exploit release, with honeypots receiving tens of thousands of attempts and more than 100 attacker-created administrator accounts observed across affected environments.
  • Malicious plugins and web shells survive ordinary WordPress sessions and provide a durable route to filesystem, database, credential, and application-secret access.
  • Wiz telemetry found that 25% of organizations using WordPress exposed a vulnerable server to the internet when the CVEs were published; that figure fell to 10% within 24 hours, but previously exposed systems still require compromise assessment.

Affected and fixed releases

  • Combined pre-auth RCE chain: WordPress 6.9.0–6.9.4, fixed in 6.9.5; and 7.0.0–7.0.1, fixed in 7.0.2.
  • CVE-2026-60137 SQL injection without the CVE-2026-63030 default-install chain: WordPress 6.8.0–6.8.5, fixed in 6.8.6. The SQL-injection CVE record says exploitation on this branch requires a plugin or theme to pass untrusted input into author__not_in.
  • WordPress.org released 7.0.2 on 2026-07-17 and the WordPress update API lists 7.0.2, 6.9.5, and 6.8.6 as current security releases for their respective branches.

Observed exploitation

  • Entry point: requests abuse /?rest_route=/batch/v1 or /wp-json/batch/v1.
  • Plugin upload: Wiz observed access to /wp-admin/plugin-install.php?tab=upload followed by POST /wp-admin/update.php?action=upload-plugin to install persistent backdoors.
  • User discovery: requests to /wp-json/wp/v2/users?context=edit harvested administrator usernames and email addresses.
  • Credential-file targeting: local-file-inclusion attempts used admin-ajax.php?template=../../../wp-config to seek database credentials and authentication keys.
  • Authenticated access: successful HTTP 200 responses from /wp-admin/ indicated attacker-controlled authenticated sessions after exploitation.
  • Scanning: high-volume batch-endpoint probing occurred alongside successful compromises; not every request implies code execution.
  • Public-exploit escalation: watchTowr reported early credential-hash exfiltration followed by RCE as further details became public, widespread indiscriminate spraying, fake plugin deployment, secondary tooling, and at least one attempted Overlord RAT installation.
  • Independent sensor telemetry: KEVIntel reported 35 attempts from 13 unique attacker IPs across eight sensors as of 2026-07-21. Treat aggregate counts as confirmation of active exploitation, not an estimate of total internet volume.

Payloads and persistence

Wiz described three PHP backdoor shapes:

  1. A minimal one-line eval web shell that accepts a secret POST parameter and returns HTTP 404 when it is absent.
  2. A roughly 150 KB web shell disguised as a WordPress plugin named CMSmap. The sample uses a graphical interface, password authentication, file and database management, port scanning, batch code injection, and privilege-escalation modules. Its payload is hidden with hex-string concatenation and eval(gzuncompress(base64_decode(...))).
  3. A malicious plugin that registers an unauthenticated custom REST route under /morning/v1/…, base64-decodes a supplied command, executes it with passthru, and returns output as JSON.

Do not rely on a single filename or plugin slug: the observed backdoors range from trivial one-liners to full-featured plugin-shaped shells.

Detection and triage

  • Search reverse-proxy, CDN, WAF, and origin logs for requests to /?rest_route=/batch/v1 and /wp-json/batch/v1, especially HTTP 200 or 207 responses followed by admin, plugin-upload, user-enumeration, or file-inclusion activity.
  • Hunt user-agent strings containing wp2shell or rezwp2shell; Wiz reports these as purpose-built exploit-tool signatures, but absence does not rule out exploitation.
  • Review access to /wp-admin/plugin-install.php?tab=upload, POST /wp-admin/update.php?action=upload-plugin, /wp-json/wp/v2/users?context=edit, anomalous /wp-admin/ sessions, and traversal-style admin-ajax.php parameters.
  • Inventory plugins and compare them with known-good deployment state. Investigate newly installed, unexpectedly activated, unsigned, or locally modified plugins and custom REST routes, including routes under /morning/v1/.
  • Inspect WordPress Core, wp-content/plugins, wp-content/mu-plugins, themes, and uploads for new or modified PHP files, one-line eval shells, gzip/base64 runtime unpacking, permissive REST callbacks, passthru, shell_exec, and similar command-execution functions.
  • Review database users, roles, options, scheduled actions, cron, .htaccess, wp-config.php, PHP configuration, web-server configuration, and hosting-panel state for persistence or credential access.

Public indicators

The following were published by Wiz as exploitation or payload pivots. Treat shared infrastructure as investigative context rather than standalone attribution.

Exploitation and scanning addresses

  • 45.79.167[.]238
  • 34.81.132[.]62
  • 79.177.131[.]206
  • 15.157.135[.]170
  • 94.100.52[.]128
  • 172.235.128[.]52 — reported as mass scanning

PHP web-shell hashes

  • 2a1410d8e2a8337ac2171cedea8c0fdc47c647a0
  • 58eca847e9eae9e6b08cc211f1559817b71bc4cc
  • ebea44890f434d5d67ede22009a3f4bb5cac33f8
  • d9a220c8039f1c4d72cae7ccb8b3a33dec8815be
  • e9756e2338f84746007235e4cab7a70d5b3ca47f

Response guidance

  1. Update immediately to 7.0.2, 6.9.5, 6.8.6, or a newer supported release as appropriate. Confirm the effective runtime version rather than assuming background updates completed.
  2. Treat prior internet exposure as a compromise-assessment trigger. Patching closes the vulnerability but does not remove uploaded plugins, web shells, stolen sessions, or harvested secrets.
  3. If patching cannot happen immediately, temporarily block unauthenticated access to both batch-route forms at the WAF or disable anonymous REST API access. Validate application impact and remove the temporary restriction after patching; filtering is not remediation. Cloudflare published blocking rules for both CVEs and advises customers to verify that ruleset overrides have not changed the new rules from Block to Log.
  4. Preserve CDN/WAF/origin logs, WordPress and PHP logs, filesystem timestamps, plugin inventories, database snapshots, process telemetry, and volatile evidence before cleanup where incident response matters.
  5. On confirmed or credible exploitation, isolate the host; rebuild from known-good artifacts where possible; rotate WordPress salts and keys, administrator and application passwords, database credentials, hosting/control-panel credentials, deployment keys, cloud credentials, and secrets readable by the web process; invalidate active sessions.
  6. Check adjacent infrastructure and cloud accounts for follow-on access. Wiz had not observed lateral movement or data exfiltration at publication time, which is not evidence that an individual compromised environment remained contained.

Attribution caveats

Wiz reported multiple actors and opportunistic mass scanning. The published indicators do not establish a single campaign or actor, and the CMSmap disguise is not evidence that the legitimate CMSmap project participated in the activity.

Sources