WordPress Core Upgrade Flaw Under Attack: Nearly 63,000 Exploit Attempts in 24 Hours

Attackers wasted no time. Within two days of WordPress shipping version 7.1.4 on 28 October 2026, exploitation attempts against the high-severity flaw it fixes were already running at tens of thousands per day. The vulnerability allows unauthenticated remote code execution on sites running WordPress Core 4.7 through 7.1.3 and carries a CVSS score of 8.1. At the time of writing it has not been assigned a CVE identifier.

What happened

The weakness sits in a mundane place: the way WordPress unpacks a full-package core update. When a site installs a complete core release (as opposed to a partial update), the new files are extracted into a temporary staging folder under wp-content/upgrade before they are moved into place. Two details turn this housekeeping step into an attack surface:

• the staging path is predictable, and on many hosting setups it is reachable from the web and executes PHP;
• the staged copy includes the WordPress installer, including setup-config.php.

An unauthenticated attacker who requests the staged installer at exactly the right moment can drive it against the half-installed copy and reach PHP code execution on the server. It is a race condition: in lab conditions the window is only a few seconds long, closing when WordPress finishes the upgrade and removes the temporary files.

For a successful attack all of the following must line up:

1. a full-package update that contains the installer files is being applied;
2. the staging tree is publicly accessible over the web and PHP runs from it;
3. the attacker knows or guesses the staging path;
4. the attacker completes the sequence before cleanup.

Why it matters

A seconds-wide window sounds unexploitable. The traffic says otherwise. Telemetry from WordPress firewall deployments recorded close to 63,000 blocked requests targeting the flaw in a single 24-hour period. Two of the biggest sources hammered small groups of sites for roughly fourteen and a half hours each, polling the installer path over and over in the hope of landing inside an upgrade. Others fanned out, trying many staging-directory and version-name variations to find the right one.

Not every request hit the exact vulnerable path, but the sustained polling and layout-specific probes show the attackers understood the race condition quickly and built tooling for it. Because the trigger is the site's own update process, the sites most at risk are precisely the ones doing the right thing: patching. Sites on shared hosting, where the upgrade folder is commonly web-readable, are the most natural targets.

What to do

• Update to WordPress 7.1.4 now. Every release from 4.7 up to 7.1.3 is affected. Confirm the version on each site, not just the ones you remember.
• Check your web-server logs for requests to PHP files under wp-content/upgrade, especially repeated hits on setup-config.php or on version-named subfolders. Repeated polling of that path from a single source is a strong signal.
• Hunt for persistence. Review administrator accounts, installed plugins and must-use plugins, and look for PHP files you did not put there, in uploads and theme directories in particular.
• Harden the staging directory. Where your hosting allows it, deny web access to wp-content/upgrade or disable PHP execution inside it. This also blunts future variants of the same idea.
• Keep patching. The flaw is only exposed while an upgrade runs, so the fix is to be on a version where the staging step is safe, not to stop updating.

Flaws like this one are easy to miss precisely because the vulnerable component is not a plugin or a theme but a few seconds inside a routine process. Keeping an accurate inventory of which WordPress version each site runs, and getting alerted the day a release falls behind, is the kind of problem our vulnerability scanning service is built to solve: it flags outdated core versions across your estate so a two-day patch gap does not become a two-month one.