>samit_hota
Back to advisories
SH-2026-163CriticalResolved

Critical WordPress Pre-Auth RCE and SQLi Vulnerabilities Patched, Public PoC Available

Samit Hota·
CVE ID
CVE-2026-63030, CVE-2026-60137
CVSS Score
N/A
Affected Products
WordPress Core versions 6.8.0-6.8.5, 6.9.0-6.9.4, 7.0.0-7.0.1
#news#wordpress

Overview

WordPress, the world’s most popular content management system, has released urgent security updates to address two critical vulnerabilities: a pre-authentication Remote Code Execution (RCE) flaw (CVE-2026-63030) and an associated SQL Injection (SQLi) vulnerability (CVE-2026-60137). These vulnerabilities impact WordPress Core versions 6.9.0-6.9.4, 7.0.0-7.0.1 (for RCE) and 6.8.0-6.8.5 (for SQLi-only). WordPress released version 7.0.2 on July 17, 2026, to address these issues, alongside 6.8.6 and 6.9.5, and has enabled forced automatic updates for affected installations. The situation is particularly critical as a working public proof-of-concept (PoC) for the RCE has been reported as of July 18, 2026, significantly increasing the risk of widespread exploitation.

Technical Details

The wp2shell RCE vulnerability (CVE-2026-63030) is the result of a two-vulnerability chain that leverages both a REST API batch-route confusion and a WP_Query Injection SQL flaw. The REST API batch-route confusion allows an attacker to manipulate how WordPress processes multiple API requests in a single batch. This, in conjunction with the WP_Query Injection SQL flaw (CVE-2026-60137), creates the path for pre-authentication remote code execution.

The companion vulnerability, CVE-2026-60137, exists in the author__not_in parameter handled by WP_Query. WP_Query is a fundamental component of WordPress Core, themes, and plugins used to construct database queries. The flaw arises because the author__not_in parameter, intended to represent a list of numeric author IDs, is not properly normalized into a list of integers before it is used in SQL query construction. This lack of sanitization allows an attacker to inject arbitrary SQL code, leading to an SQL injection. When chained with the REST API confusion, this SQLi can be elevated to pre-authentication RCE on affected versions, meaning an attacker does not need to be logged in to exploit the vulnerability. The availability of a public PoC means the technical barrier to exploitation is dramatically lowered, making rapid exploitation attempts highly likely.

Real-World Impact

The real-world impact of these WordPress vulnerabilities is severe, given the widespread adoption of the CMS.

  • Complete Website Compromise: A successful pre-authentication RCE allows an attacker to execute arbitrary code on the web server. This grants them full control over the affected WordPress website, including the ability to deface it, inject malware, steal sensitive data (e.g., user credentials, customer information), or use the site as a launchpad for further attacks.
  • Data Breach: The SQL injection component, even independently, can lead to the unauthorized disclosure or manipulation of database contents, including user data, post content, and site configurations.
  • Supply Chain Attacks: Compromised WordPress sites can be used to host malicious content, distribute malware to visitors, or serve as part of larger attack campaigns, potentially impacting the users of these sites.
  • Reputational Damage and Financial Loss: For businesses, a compromised website can lead to significant reputational damage, loss of customer trust, and substantial financial costs associated with incident response, forensic analysis, and potential regulatory fines.
  • Automated Exploitation: With a public PoC available, automated scanning and exploitation tools are likely to emerge rapidly, putting unpatched WordPress sites at immediate and severe risk.

Threat Landscape

The disclosure of critical pre-authentication RCE and SQLi vulnerabilities in WordPress Core, coupled with a public PoC, represents a significant event in the web application security landscape. WordPress’s ubiquity makes it a prime target for attackers, and vulnerabilities that do not require authentication are particularly attractive. This incident highlights the ongoing challenges of securing complex software ecosystems where interactions between different components (like the REST API and database query functions) can introduce unexpected attack vectors. The rapid availability of a public PoC underscores the critical need for immediate patching, as the window for safe remediation before widespread attacks may be very narrow. This also reinforces the importance of defense-in-depth strategies, even for widely used and generally secure platforms like WordPress.

Remediation

Immediate and decisive action is critical for all WordPress administrators.

  • Patch Immediately: All WordPress installations on affected versions (6.9.0–6.9.4, 7.0.0–7.0.1, and 6.8.0–6.8.5) must be updated to the patched versions (6.8.6, 6.9.5, and 7.0.2) immediately. While WordPress supports automatic updates, verify that the update was successful, as failures can occur due to various factors (e.g., file permissions, hosting configurations).
  • Monitor for Compromise: Given the public PoC, assume that unpatched sites may already be targeted or compromised. Conduct a thorough forensic analysis for any signs of exploitation, including unusual file modifications, new user accounts, or suspicious database entries.
  • Web Application Firewall (WAF): Deploy or ensure your WAF is configured to detect and block known RCE and SQLi attack patterns. Update WAF rules with any available signatures specific to CVE-2026-63030 and CVE-2026-60137.
  • Regular Backups: Maintain recent and verified backups of your WordPress site, including both files and databases, stored securely off-site.
  • Least Privilege: Ensure all WordPress users and database users operate with the principle of least privilege.
  • Security Scanning: Regularly scan your WordPress installation for vulnerabilities, malware, and integrity compromises.
  • Disable Unused Features: Disable any WordPress features or plugins that are not actively used to reduce the attack surface.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call