62,969 exploit attempts hit WordPress days after patch

Wordfence blocked 62,969 attempts to exploit a WordPress Core remote code execution flaw in a single 24-hour window, days after the patch shipped on October 28, 2026. The bug has no CVE identifier and carries a CVSS score of 8.1. It affects WordPress Core versions 4.7 through 7.1.3, with the fix in 7.1.4.

The vulnerability lives in the upgrade process, not the running site. When WordPress applies a full-package Core update, it unpacks the complete set of new files into a staging directory under wp-content/upgrade, and that copy includes the WordPress installer. On many servers that directory is web-accessible and PHP executes there. An unauthenticated attacker who requests the installer while the staged copy is on disk can interact with it and drive it to PHP code execution. The path being polled is setup-config.php.

Exploitation is a race condition. WordPress unpacks the files, runs the upgrade, then deletes the temporary tree. In Wordfence’s lab that window lasted only seconds. Alex Thomas, who leads the Wordfence Threat Response Team, listed the conditions an attacker needs to win it: a full-package update that contains the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time to finish before WordPress cleans up. Wordfence describes the staging paths as predictable by default, which removes the hardest of those four for the attacker.

Because the vulnerable state only exists during an upgrade, attackers cannot force the window open. They poll and wait for a site to start updating. “Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window,” Thomas said. Other sources tested many staging-directory and version-name variations. Not every request used the exact vulnerable path, but the sustained polling and exact-layout probes show attackers understood the race condition quickly and began targeting it.

That inverts the usual patch-timing logic. The danger is highest at the moment you apply an update, and a site already running 7.1.4 has closed the window for good. The 62,969 figure is one day of blocked traffic from one vendor, so read it as a floor on activity rather than the full picture.

If you run WordPress, update to 7.1.4. Then check the logs for suspicious requests to PHP files under wp-content/upgrade, and look for administrator accounts, plugins, or PHP files you do not recognize.