WordPress 7.0.2 has been released to address two security vulnerabilities, a high-severity SQL injection vulnerability and a critical pre-authentication remote code execution (RCE) vulnerability.
The SQL injection issue affects WordPress 6.8 and later, while the RCE vulnerability affects WordPress 6.9 and later. Both vulnerabilities have been fixed in WordPress 7.0.2 and 6.9.5. WordPress 6.8.6 includes a fix for the SQL injection vulnerability, while WordPress 7.1 Beta 2 includes fixes for both issues.
Due to the severity of the vulnerabilities, the WordPress.org team has pushed out forced updates through its auto-update system.
From SQL Injection to RCE: Researchers detail the WordPress exploit chain
The facilitated SQL injection vulnerability was reported by TF1T, dtro, and haongo. Adam Kues of Assetnote / Searchlight Cyber discovered the second vulnerability, a REST API batch route/handler confusion issue that can lead to remote code execution.
Kues described the vulnerability as a pre-authentication RCE that can be exploited by an anonymous user on a standard WordPress installation without plugins or other preconditions. They have named the vulnerability as wp2shell, while a public tool at wp2shell.com is available to help users check whether their WordPress installation is affected.
Kues later provided more details about how the vulnerability was discovered, saying he used GPT5.6 Sol Ultra to analyze the WordPress codebase for a pre-authentication path to remote code execution. The model first identified the SQL injection, which Kues verified on a stock WordPress installation, and later found a way to escalate the issue to RCE. According to Kues, the full exploit chain was developed in just over 10 hours, with the total usage costing approximately $25. He said he then spent considerably longer analyzing and documenting the chain himself.
Patchstack’s analysis found that the vulnerabilities form a two-stage attack chain. The first issue is a facilitated SQL injection vulnerability in WP_Query, which affects WordPress 6.8 and later. It involves the author__not_in query variable. In the vulnerable code, WordPress sanitized the value only when it was received as an array. If the value arrived as a string, that sanitization was skipped, allowing the raw value to be passed into the SQL query.
The second vulnerability, introduced in WordPress 6.9, affects the REST API’s batch endpoint. According to Patchstack, an indexing problem can cause the endpoint to lose alignment between a request and the handler that processes it. This means a request can be validated using one handler but executed using another. As a result, input that would normally be rejected by the appropriate validation can reach WP_Query, where it can trigger the SQL injection vulnerability.
The scale of the ongoing exploitation was also highlighted by Oliver Sild (CEO of Patchstack), who said his team was tracking more than 1,200 unique IP addresses involved in mass exploitation of the WordPress pre-authentication RCE.
Also, Danny van Kooten warned WordPress users with DISALLOW_FILE_MODS enabled to pay particular attention to updating their sites to version 7.0.2. He said one of his sites had already been compromised, with the attacker changing his administrator password, creating several new administrator accounts, and accessing the site. Although the site was later secured, Van Kooten warned that the vulnerability was already being exploited at scale.
From WAF rules to virtual patches
Cloudflare deployed WAF protections for both vulnerabilities after receiving information from the WordPress security team before public disclosure. GoDaddy said it would automatically deploy the patched version for Managed Hosting for WordPress and Pagely customers, while also adding additional safeguards for Web Hosting customers.
InstaWP said it deployed an origin-level virtual patch across its fleet to block exploit attempts before they reached WordPress. The company later said a forensic review confirmed active exploitation and found a small number of compromised sites from before the protection was deployed. InstaWP also released the open-source, read-only wp2shell-scan tool to check logs, site files, and users for signs of compromise.
Also, InstaWP said it did not force-update WordPress because customers on its development and staging platform often intentionally pin WordPress versions, and automatic core updates are disabled on most sites by design. The company said forcing an update could disrupt work in progress, plugins under test, or reproduced bugs. Instead, its virtual patch allowed it to block the vulnerability without changing customer files.
Mullenweg highlights the rare RCE and solidarity during the response
Matt Mullenweg highlighted the rarity of the pre-authorization remote code execution vulnerability discovered by Adam Kues. He said that this type of RCE has only appeared a few times in WordPress’s 23-year history, “ One is a type of pre-authorization RCE we (fortunately!) have only seen a few times in WordPress’ 23-year history; the last, I believe, in the PHPMailer class five years ago. “
Mullenweg also praised people and organizations that “otherwise might not be on the best of terms” for coming together during the response, adding that “Everyone buries the hatchet to protect as many people as possible as quickly as possible.”
He also said that the vast majority of WordPress sites were protected by defense-in-depth measures even before the security updates were released.
Looking ahead, Mullenweg said security will be a major topic this year as the technology industry responds to advances in AI models. He said it is a good time to “review your plans and processes, sweat the details, invest in maintenance, and hug a sysadmin.”