Four days ago, WPWithin covered WordPress 7.0.2, the emergency release that fixed a critical flaw letting an anonymous attacker take over a plain WordPress site. Security firm Patchstack has now published what happened next: attackers started firing at the bug roughly 90 minutes after the fix went out, and unpatched sites are still being hit.
How fast the attacks started
Patchstack says the first real exploitation attempts hit its sensors about 90 minutes after WordPress 7.0.2 was released, and only three hours after the underlying code fix was committed. That is the normal pattern for a bug like this one: attackers compare the patched code to the old code, work out what changed, and turn that difference into a working exploit. The gap between “a fix exists” and “attackers can use it” is now measured in hours, not days.
In the days since, Patchstack logged more than 65,000 exploitation attempts from over 1,500 unique IP addresses. Its telemetry sits inside the WordPress installs it protects, so it can confirm something important: every attempt it logged targeted a site still running a vulnerable version. Patched sites were not affected.
What the bug actually does
The chain combines two flaws WPWithin covered when the news broke, plus in yesterday’s story about how a researcher found it using an AI model. A SQL injection bug in WP_Query (CVE-2026-60137, affecting WordPress 6.8 through 7.0.1) combines with a REST API mix-up (CVE-2026-63030, affecting 6.9 through 7.0.1) to let an attacker with no account on your site create an administrator account and install a webshell, a hidden file that gives them ongoing control.
Most of the traffic Patchstack observed was early-stage probing aimed at the REST API endpoint, the kind of scanning that happens before an attacker commits to a full attack. A smaller cluster of requests went straight for the complete chain: create an admin account, then drop a webshell, with no probing first. That suggests some attackers already had working exploit code ready to go the moment sites were confirmed vulnerable.
What to do
If you have not confirmed your site is updated, do it now. Log in to your WordPress dashboard, click Updates, and check that your version reads 7.0.2, 6.9.5, or 6.8.6. If you manage multiple sites, check each one individually rather than assuming a host-wide update caught everything.
If your site was running a vulnerable version for any length of time before you patched, it is worth a quick look through your admin users for accounts you do not recognize, and a scan of your plugin and upload folders for PHP files that should not be there. Most hosts and security plugins log this kind of activity automatically, so check those logs first before assuming the worst.
End of article