Ninety Minutes to Weaponized: Inside the WordPress Core RCE Race

On July 17, 2026, the WordPress core team tagged version 7.0.2 to fix a two-part vulnerability chain that allows unauthenticated remote code execution. Within about ninety minutes of that release, attackers had already reverse-engineered the patch and were sending live exploit payloads at WordPress sites across the internet. Patchstack logged more than 65,000 blocked exploitation attempts against these flaws in the days that followed, originating from over 1,500 unique IP addresses.

What makes this incident stand out is not the bug itself, but the speed at which it moved from a public commit to weaponized internet-wide scanning. The timeline below breaks down the chain, the exploitation traffic, and the practical steps site owners should take now.

Key Takeaways

• The flaw is actually two CVEs that chain together: a facilitated SQL injection in WP_Query and a route confusion in the REST API batch endpoint.
• Both issues are fixed in WordPress 7.0.2, 6.9.5, and 6.8.6. Branches older than 6.8, including 6.1 and 6.2, are not affected by this specific chain.
• Attackers started exploiting the chain roughly ninety minutes after 7.0.2 was released, about three hours after the fix was committed to trunk.
• Approximately 97 percent of blocked traffic targeted the REST batch endpoint, and around three-quarters carried a malicious author_exclude parameter.
• Block data only shows attempts, not completed compromises, but on an unpatched site the same requests walk straight from probing to admin creation to code execution.

The Two CVEs Behind the Chain

Neither vulnerability is a solo takeover bug. Combined, however, they give an unauthenticated visitor a path from a public HTTP request all the way to executing code on the server.

Once the batch confusion delivers the injection into WP_Query, the public exploit walks from there to creating a new administrator and then to executing server-side code. Both CVEs were patched in the same coordinated release on July 17, 2026.

Ninety Minutes From Patch to Payload

The fix landed in WordPress core about 1.5 hours before 7.0.2 was tagged. That commit acts as public disclosure, since anyone watching core development can diff the change and understand both the vulnerable code and the patch.

Patchstack recorded the first real exploitation attempts roughly ninety minutes after 7.0.2 shipped, or about three hours after the commit. That is the runway defenders had to deploy updates before live scanning started. The same window repeated across thousands of sites, because anyone who had not yet installed the security release became an instant target.

What the Exploitation Traffic Looked Like

Most campaigns of this type look like a coordinated botnet. This one looked more like a land rush, with many independent actors converging on the same opportunity at once.

• More than 1,500 unique source IPs participated.
• The single busiest network accounted for only 6.45 percent of traffic. The top ten networks combined for around 22 percent.
• Almost all the source ranges sat in VPS and cloud providers such as Vultr (Choopa), M247, and HostPapa, with a long tail of hosting networks.

Two patterns dominate the requests themselves. Second, around three-quarters of the blocked requests carried an SQL injection payload inside the author_exclude parameter, using mixed-case keywords, inline comments, MySQL conditional comments, and URL encoding to vary their signatures.

Patchstack only sees blocked attempts at the application layer. On a site still running 6.9 or 7.0.0/7.0.1, the same requests continue on to administrator creation and remote code execution.

Why the Speed Matters

A ninety-minute weaponization window is not unusual for high-severity WordPress core bugs anymore. Because of that pace, the patch latency on any individual site is the single biggest risk factor. A site that updates within a few hours is largely safe. A site that waits days or weeks sits directly in the path of automated exploitation.

The mix of networks involved also reinforces a familiar truth: many of these source IPs are rented infrastructure, not classic residential botnets. Attackers spin up short-lived VPS instances to run their scans, which limits the value of static IP blocklists and raises the importance of keeping the application itself patched.

What Site Owners Should Do Right Now

If you run WordPress, treat the next 24 to 48 hours as the active exploitation window for this chain and prioritize accordingly. The fix versions are 7.0.2, 6.9.5, and 6.8.6.

• Confirm your current core version from the Dashboard Updates screen or your hosting control panel.
• Update to 7.0.2, 6.9.5, or 6.8.6 depending on your branch. Older branches are not affected by this chain.
• If you maintain a enterprise WordPress change management pipeline, treat this release as an emergency change and document the deployment window.
• If a site cannot be updated immediately, block requests to /batch/v1 and /wp-json/batch/v1 at the WAF or web server level until you can patch, and monitor administrator accounts for unexpected additions.
• After patching, audit recent admin users, scheduled tasks, and theme or plugin files for modifications you did not make. Reference the how to fix critical error in WordPress guide if you need to recover from a compromised install.

Frequently Asked Questions

What versions of WordPress are affected by the July 2026 core RCE?

The chain affects WordPress 6.8 through 7.0.1 and is fixed in 7.0.2, 6.9.5, and 6.8.6. Branches older than 6.8, including 6.1 and 6.2, do not contain the vulnerable code paths involved in this chain.

Did attackers really start exploiting the bug within ninety minutes?

Yes. Patchstack recorded the first exploitation attempts roughly ninety minutes after WordPress 7.0.2 was tagged and about three hours after the fix was committed to core. Within days, more than 65,000 attempts had been blocked across over 1,500 unique IP addresses.

Why is the REST batch endpoint at the center of the attack?

CVE-2026-63030 lets an attacker use the batch endpoint to smuggle inner requests past the schema checks that would normally reject them. That is why about 97 percent of the blocked traffic targeted /batch/v1 and its ?rest_route= equivalent, with the malicious logic hidden inside nested request arrays.

What damage can the chain cause on an unpatched site?

On an unpatched site the chain lets an unauthenticated visitor move from public probing to creating a new administrator account and then to executing code on the server. Patchstack only sees blocked attempts at the application layer, so the same requests that stop there will continue on to full compromise without an in-app mitigation or a working patch.

Is a Web Application Firewall enough to protect my site?

Application-layer mitigations such as Patchstack RapidMitigate can hold the line against this specific chain, and many network WAFs can block common payload shapes. However, an unpatched WordPress core is still a liability: the safe state is running 7.0.2, 6.9.5, or 6.8.6 with version-appropriate mitigations removed, rather than relying on filter rules indefinitely.

Action Checklist

• Verify your WordPress core version today and confirm whether it falls in the 6.8 to 7.0.1 range.
• Update to 7.0.2, 6.9.5, or 6.8.6 as soon as maintenance windows allow.
• If you need a quick reference for reinstalling core files, follow how to restore WordPress core through control panel.
• Review administrator accounts, scheduled events, and core files for post-exploitation indicators after patching.
• Schedule weekly security update reviews so the next core release lands within hours, not days, of publication.
• If you are setting up a new site, use the steps in how to install WordPress in your domain to start on a supported branch from day one.

WordPress site owners who keep core updated within hours of release have largely stayed ahead of this campaign. Those who delay by even a day have ended up inside the exploitation window. Patch first, audit after, and keep your update process measured in hours rather than weeks.