Attackers Weaponized WordPress Core RCE in 90 Minutes

Attackers began exploiting a critical WordPress core remote code execution (RCE) chain just 90 minutes after the patched release went public, according to new research from Patchstack. The security vendor, which sells web application firewall and vulnerability services for WordPress, says it blocked more than 65,000 exploitation attempts against the two underlying vulnerabilities in the days after disclosure. Those attempts came from more than 1,500 unique IP addresses, and nearly all of them targeted unpatched sites running vulnerable versions of WordPress. The speed at which the attack campaign started shows that website owners have almost no time between a fix being published and criminals trying to use the flaw.

The incident involves two separate flaws that can be combined into one takeover. The first, CVE-2026-60137, is a SQL injection in a part of WordPress called WP_Query through the author_exclude or author__not_in parameter. A SQL injection happens when an attacker places database commands into input that the website then runs; in this case the injection is read-only, meaning it can read information from the site database but cannot write to it directly. That flaw affects WordPress versions 6.8 through 7.0.1. The second flaw, CVE-2026-63030, is a route and handler confusion in the REST API batch endpoint at /batch/v1. The REST API is a way for outside programs to talk to WordPress, and the batch endpoint lets multiple actions be sent at once. This flaw affects versions 6.9 through 7.0.1. On their own, neither flaw gives an attacker full control. But when chained, the batch confusion lets an unauthenticated request sneak the SQL injection past the normal data checks, and a public exploit then creates a new administrator account and eventually gains remote code execution. The fixes were released in WordPress 7.0.2, 6.9.5, and 6.8.6. Older branches such as 6.1 and 6.2 are not affected, because the vulnerable code was only introduced in 6.8 and 6.9.

Patchstack's telemetry shows how quickly the campaign began. The fix was committed to the WordPress development trunk about 1.5 hours before version 7.0.2 was tagged for release. Because anyone can watch the code changes, that commit effectively acted as public disclosure. The first real exploitation attempts reached Patchstack's sensors roughly 90 minutes after 7.0.2 was released, and three hours after the fix was committed. Over the following days, Patchstack blocked more than 65,000 exploitation attempts from over 1,500 unique IP addresses. The company notes that its RapidMitigate feature only activates mitigation rules on websites that actually run a vulnerable version, and it removes those rules after the site is patched, so the blocked attempts were all aimed at unpatched systems. The traffic was also observed inside the application itself, meaning any network or server level firewall in front of the site had already allowed the request to pass. No single network dominated the traffic; the busiest network accounted for only 6.45 percent, and the top ten networks together made up about 22 percent. The attacking IPs came mainly from cloud and VPS providers like Vultr (Choopa), M247, and HostPapa. Nearly all of the blocked traffic was early stage SQL injection probing, but on an unprotected site the same request would continue all the way to admin creation and code execution.

The traffic gave a clear picture of how attackers worked. Almost 97 percent of everything Patchstack blocked targeted the REST batch endpoint. Attackers used two main ways to reach it: /?rest_route=/batch/v1 and /wp-json/batch/v1, with the first being more common. They also sprayed path variants such as /index.php?rest_route=/batch/v1, /wp/?rest_route=/batch/v1, /blog/?rest_route=/batch/v1, and /wp-json?rest_route=/batch/v1 to get past simple filtering rules. Around three quarters of the blocked requests included a SQL injection attempt in the author_exclude parameter, and the payloads used mixed case keywords, inline comments, database-specific conditional comments, and URL encoding to hide themselves. The researchers split the requests into two groups. The much larger group was validation probes, such as AND (1=1), AND (1=2), or OR SLEEP(5), used to check whether a site was vulnerable before spending more effort. A much smaller but more serious group carried the full published privilege escalation chain and went straight for administrator creation, with a batch request that would call POST /wp/v2/users and set roles to administrator. Those full chain attempts came from just three IP addresses: 129.121.77.134, 91.202.233.61, and 125.164.233.50.

Patchstack also reports that its own RapidMitigate rules for the two vulnerabilities were deployed the moment the advisory went out, before the first attempts arrived. During the campaign, 99.9 percent of all blocked attempts were stopped by those two specific WordPress core vulnerability rules, while additional generic rules barely registered. That outcome shows that root cause rules caught the attacks before they could reach generic backstops.

For anyone still running WordPress 6.9 through 7.0.1 without the patch, the outcome is severe. The public exploit, circulated as a tool nicknamed wp2shell, uses the read-only SQL injection to forge data that WordPress then acts on. It seeds posts and a customizer changeset that lead to a fresh administrator account. Once an attacker has that admin account, they can log in, upload a plugin that is actually a web shell, and execute code on the server. Patchstack says it independently verified that the combined vulnerabilities lead to full site takeover, including remote code execution. Site owners should check for unfamiliar administrator accounts, unexpected plugins, random PHP files in the uploads directory, and anything unexpected in the mu-plugins folder, which loads automatically and does not appear on the normal Plugins screen.

There is also a warning about the mitigation rules themselves. According to Patchstack, nearly every web application firewall rule published in the first hours after disclosure shared a critical blind spot. The rules looked for batch/v1 in the request URL, because that is how the public proof of concept code reached the endpoint. But WordPress registers rest_route as a public query variable and reads those variables from the POST body before it reads them from the query string. Therefore an attacker can send a plain POST request to the site root with rest_route=/batch/v1 in the form body and the batch payload alongside it, and WordPress will route the whole thing to the batch endpoint. The URL never contains batch/v1, so any rule that only inspects the URL sees a harmless request to the site root and lets it through. A rule that only checks the URL can be bypassed with one small request change. Patchstack discovered this gap and handled it as a coordinated disclosure, first notifying affected security vendors and the WordPress