DEV Community

NetSecOpsIO
NetSecOpsIO

Posted on • Originally published at cyber.netsecops.io

wp2shell: Unauthenticated RCE in WordPress Core

Originally published on CyberNetSec.

Executive Summary

On July 17, 2026, the WordPress Security Team disclosed and patched a critical vulnerability chain named 'wp2shell'. This attack chain affects WordPress Core versions 6.9 through 7.0.1 and allows an unauthenticated attacker to achieve remote code execution (RCE) on a default installation. The attack combines two separate vulnerabilities: CVE-2026-60137, an unauthenticated SQL injection, and CVE-2026-63030, a route confusion weakness. Given that WordPress powers over 500 million websites, the potential impact is massive. The maintainers have initiated forced automatic updates to mitigate the threat, and security vendors are racing to deploy protective measures as public proof-of-concept exploits and active in-the-wild exploitation have been observed.


Vulnerability Details

The 'wp2shell' attack is not a single flaw but a chain of two distinct vulnerabilities that, when combined, escalate to RCE.

  1. CVE-2026-60137 (Unauthenticated SQL Injection): This vulnerability exists in the WP_Query class within WordPress versions 6.8 through 7.0.1. An attacker can inject malicious SQL queries through the author__not_in parameter without needing to be authenticated. This flaw can be used to leak sensitive information from the site's database, such as user credentials or other confidential data. This is a classic example of T1506 - Web-Based SQL Injection.

  2. CVE-2026-63030 (Route Confusion to RCE): This weakness, with a CVSS score of 7.5, is found in the REST API batch endpoint (/wp-json/batch/v1). By chaining this with the information leakage from the SQLi, an attacker can escalate their privileges and achieve full remote code execution on the target server. The exact mechanism of the chain allows the output of the SQLi to be used to bypass security checks in the batch processing endpoint, leading to code execution.

The attack is effective against default WordPress installations that are not configured with a persistent object cache (e.g., Redis, Memcached). Since the default configuration does not use such a cache, a vast number of websites are vulnerable out-of-the-box.


Affected Systems

  • WordPress Core: Versions 6.9 through 6.9.4
  • WordPress Core: Versions 7.0.0 through 7.0.1

The vulnerability affects sites running on these versions, particularly those without a persistent object cache enabled.


Exploitation Status

Public proof-of-concept (PoC) exploit code for the 'wp2shell' chain became available shortly after the disclosure. Multiple security firms, including Wordfence and Rapid7, have confirmed that the vulnerability is being actively exploited in the wild. The ease of exploitation and the widespread nature of the target make this a highly urgent threat.


Impact Assessment

The impact of 'wp2shell' is critical. Successful exploitation grants an unauthenticated attacker complete control over a vulnerable website. This could lead to:

  • Website Defacement: Attackers can alter the content of the website.
  • Malware Distribution: The compromised site can be used to host and distribute malware to its visitors.
  • Data Theft: Attackers can steal all data from the website's database, including user information, customer data, and order details.
  • Phishing Hub: The site can be used to host phishing pages to target other victims.
  • Further Network Compromise: The compromised web server can be used as a pivot point to attack other systems within the same network.

Given that no authentication or special configuration is required, automated, large-scale attacks are highly likely.


Cyber Observables — Hunting Hints

The following patterns may help identify vulnerable or compromised systems:

Type Value Description
URL Pattern /wp-json/batch/v1 Look for POST requests to this endpoint, especially those with suspicious or complex JSON payloads.
URL Parameter author__not_in Scrutinize GET requests containing this parameter for SQL injection syntax, such as UNION, SELECT, or encoded characters.
Log Anomaly Unexpected PHP file creation Monitor for the creation of new PHP files in writable directories like /wp-content/uploads/, which could be a webshell.
Process Name w3wp.exe or php-fpm Look for these processes spawning suspicious child processes like sh, bash, or powershell.exe.

Detection Methods

  1. Version Check: The most straightforward detection method is to check the WordPress version. If it falls within the affected ranges (6.9 - 7.0.1), the site is vulnerable and should be updated immediately.
  2. Web Server Log Analysis: Security teams should analyze web server access logs for requests matching the patterns in the Cyber Observables section. Specifically, hunt for requests to /wp-json/batch/v1 from unknown or suspicious IP addresses. This aligns with D3FEND's D3-UA: URL Analysis.
  3. File Integrity Monitoring (FIM): Use FIM tools to monitor for unexpected changes to core WordPress files or the creation of new files in upload directories. This can help detect the presence of a webshell post-compromise, a form of D3-FA: File Analysis.
  4. WAF/IPS Signatures: Deploy updated signatures for your Web Application Firewall (WAF) or Intrusion Prevention System (IPS). Vendors like Wordfence have already released rules to block 'wp2shell' exploitation attempts.

Remediation Steps

  1. Update Immediately: The highest priority is to update WordPress to a patched version. The vulnerabilities are fixed in WordPress 7.0.2 and WordPress 6.9.5. WordPress is attempting to automatically update vulnerable sites, but administrators should manually verify that their site is running a patched version. This is a direct application of D3FEND's D3-SU: Software Update.
  2. Use a WAF: A properly configured Web Application Firewall can provide a crucial layer of defense by blocking malicious requests before they reach the WordPress application. Ensure your WAF has rules specifically for 'wp2shell' or generic SQLi and RCE protection.
  3. Review for Compromise: If you were running a vulnerable version, assume the site may have been compromised. Scan for backdoors, unknown user accounts with admin privileges, and suspicious files. If compromise is found, restore from a clean backup and change all passwords and secrets.

Top comments (0)