CYBERSHIELDZONE
An incredibly severe vulnerability chain, nicknamed wp2shell, was disclosed on July 17, 2026. This flaw allows completely anonymous, unauthenticated attackers to execute arbitrary code on default WordPress installations. Because WordPress powers roughly 43% of the internet, the discovery sent shockwaves through the global security community, threatening over 500 million websites running the core platform.
Chronology of the Crisis
The security vulnerability was responsibly reported through WordPress’s HackerOne bug bounty program by researcher Adam Kues of Assetnote (the attack surface research arm of Searchlight Cyber). The SQL injection component was also flagged independently by researchers TF1T, dtro, and haongo.
Upon receiving the warnings, the WordPress Security Team immediately worked on patches, coordinating with major web infrastructure networks like Cloudflare to deploy preventive Web Application Firewall (WAF) rules. On Friday, July 17, 2026, WordPress released emergency security updates (versions 7.0.2, 6.9.5, and 6.8.6). Due to the sheer severity of the issue, WordPress.org triggered its "forced automatic update" mechanism globally.
However, the threat landscape accelerated over the weekend. By July 18, 2026, a working public proof-of-concept (PoC) exploit was published on GitHub, explaining the full mechanism. Security providers, including Patchstack, immediately reported active scanning and initial exploitation attempts in the wild targeting outdated WordPress servers.
Technical Impact and Vulnerability Chaining
What makes wp2shell devastating is that it does not depend on any third-party plugins. It functions out-of-the-box on clean installs because the flaws reside directly in the WordPress Core framework. The attack path successfully chains two distinct vulnerabilities:
1. CVE-2026-63030 (REST API Batch Route Confusion): Classified as improper access control, this flaw is located in the core REST API batch endpoint (`/wp-json/batch/v1`), introduced in WordPress 6.9. It allows anonymous attackers to bypass REST route boundaries. 2. CVE-2026-60137 (SQL Injection in WP_Query): This SQL injection exists in the `author__not_in` parameter of the `WP_Query` core class—the primary driver for database calls. It has existed in WordPress since version 6.8.
Separately, these vulnerabilities are difficult to weaponize. But when chained together, the REST API route confusion allows unauthenticated users to trigger the database injection. This gives attackers a path to escalate privileges, inject administrative sessions, or execute arbitrary PHP code, resulting in complete server compromise (RCE).
The vulnerability exposure splits across different versions:
- WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1: Highly vulnerable to the full unauthenticated RCE chain (mitigated in 6.9.5 and 7.0.2).
- WordPress 6.8.0 to 6.8.5: Affected only by the standalone SQL injection (mitigated in 6.8.6).
- Versions below 6.8: Completely unaffected.
How to Protect Your WordPress Infrastructure
Since active in-the-wild exploitation is underway, immediate action is required:
- Verify the Update Status: Do not assume the background auto-update succeeded. Web server filesystem permission locks, disabled WP-Cron processes, containerized deployment systems, or custom hosting setups often block auto-updates. Log into your server dashboard or run CLI checks to verify your site is on 7.0.2, 6.9.5, or 6.8.6.
- Implement Temporary WAF Rules: If you cannot update your environment immediately, block the attack vector. Use your WAF or server configuration to block incoming traffic targeting the `/wp-json/batch/v1` endpoint or requests containing the query string `rest_route=/batch/v1`.
- Perform Threat Hunting: Review your HTTP access logs for unexpected POST requests sent to the REST batch endpoint. Perform integrity checks of all core PHP files to ensure no remote backdoors were planted during the exposure window.