HIGH: WordPress 7.1.4 Upgrade Flaw Draws 63,000 Attacks in a Day

There is a special kind of irony in a vulnerability that only exists while you are applying security updates. WordPress shipped version 7.1.4 on October 28 to fix a flaw in its own core upgrade process, and within two days attackers were camped outside thousands of sites waiting for the exact moment those sites tried to patch themselves. Wordfence says it blocked 62,969 attack attempts aimed at the bug in a single 24 hour period. For a platform that runs a large share of the web, that is not background noise. That is a crowd.

The flaw has no CVE assigned yet. It is tracked as GitHub advisory GHSA-4w3m-c66w-69mg and carries a CVSS score of 8.1, which lands it in high rather than critical territory. Do not let that number lull you. The score reflects how hard the attack is to pull off, not how bad the outcome is when it works. When it works, an unauthenticated stranger gets PHP code execution on your web server. Every version of WordPress Core from 4.7 through 7.1.3 is affected, which covers almost a decade of releases.

What actually goes wrong during an upgrade

To understand this bug you have to picture what WordPress does when it updates itself. When a site pulls down a full core package, it unpacks the new files into a staging directory under wp-content/upgrade before copying them into place. According to Wordfence, the problem is that those staging paths are predictable and reachable from the web. The unpacked copy includes the WordPress installer, the same setup-config.php logic you click through when you build a brand new site. If an attacker can request that staged installer while it sits on disk, they can walk it toward PHP code execution without ever logging in.

The catch, and it is a real catch, is timing. Several things have to line up at once. The site has to be applying a full package update that contains the installer files. The web server has to allow public access to the staging tree and has to execute PHP there. The attacker has to know or guess the staging path. And the whole thing has to finish before WordPress cleans up its temporary files. In lab testing that window has been measured in seconds. This is a race condition in the most literal sense, and the attacker needs to win the race against your own update routine.

The WordPress release notes describe it more vaguely as a weakness in the upgrade process that can allow remote code execution during the upgrade window. Credit goes to researcher Umut Bayram. It sits at the top of a 7.1.4 release that also fixes a pile of stored cross site scripting bugs in the Interactivity API, the Customizer, and various blocks, plus an unauthenticated information leak involving unpublished Customizer changesets and a bundled root certificate update tied to the eMudhra CA key revocation. The XSS fixes matter too, but most of them need Contributor level access or higher. The upgrade race needs nothing at all.

How attackers are playing the odds

You might reasonably ask why anyone would bother with a bug that only opens for a few seconds at a time. The answer is that automation does not get bored. Wordfence's data shows attackers repeatedly polling paths like setup-config.php inside the staging directory. The two largest sources focused on small groups of sites and hammered them for roughly 14.5 hours straight, which Wordfence reads as an attempt to be standing at the door at the moment an update kicks off. Other sources sprayed a wide range of staging directory names and version strings, trying to guess where a given site would unpack its files.

Here is the part that should make administrators uncomfortable. The upgrade window is not random. It opens when a new core release lands, and WordPress just shipped one. Every site that auto updates to 7.1.4 performs exactly the kind of full package upgrade the attack depends on. The patch run is the attack surface. Attackers know release day is when the greatest number of sites will be unpacking installers into predictable folders, and the polling patterns suggest they are timing their efforts around that.

To be fair to the defenders, Wordfence notes that not every blocked request used the precise vulnerable path, and as of this writing there are no public reports confirming successful compromises through this specific flaw. Sixty three thousand attempts in a day is still a strong signal that someone has a working approach, or at least believes they are close to one. History says that gap closes fast.

Who is actually exposed

In theory, any self hosted WordPress site running 4.7 through 7.1.3 is in scope. In practice, the realistic risk depends on how the server is configured. Hosts that block web access to wp-content/upgrade, or that refuse to execute PHP anywhere under wp-content, cut the attack off at the knees. Plenty of managed WordPress providers already lock this down. Plenty of budget shared hosting plans, the kind small businesses buy for a few dollars a month and forget about, do not.

The other factor is how updates happen. Sites with automatic background updates enabled will pull 7.1.4 on their own, which is good, but the first full package upgrade that delivers the fix is itself a moment of exposure on a vulnerable configuration. Once you are on 7.1.4 the staging behavior is fixed for future upgrades. Getting there safely is the trick. WordPress says fixes have been backported to every branch still eligible for security updates, which currently goes back to 4.7, but it also notes those backports are still rolling out. If you are running an old branch, do not assume the fix has reached you until you confirm the version number.

What to do this weekend

The first move is obvious. Get every site you manage onto WordPress 7.1.4, or the patched release for whatever branch you are stuck on. If you control the web server, the smarter sequence is to lock down the staging directory before you trigger the update. A simple rule in your web server configuration that denies all web requests to wp-content/upgrade, or that disables PHP execution under wp-content entirely except where a plugin genuinely needs it, removes the attack path no matter what version you are running. That rule should arguably have been there all along. WordPress has no legitimate reason to serve PHP from its upgrade scratch folder to the public internet.

Then go looking for evidence. Search your access logs for requests to PHP files under wp-content/upgrade, paying special attention to setup-config.php and anything that looks like an installer path. A burst of 404s against that directory tells you someone is trying. A 200 response on an installer file during an update window tells you to start an incident. After that, review the site itself. Wordfence recommends checking for administrator accounts you do not recognize, plugins you did not install, and stray PHP files that appeared recently. Compare core files against known good checksums, which the WordPress command line tool can do with a single command, and look for unexpected changes to wp-config.php.

If you run a web application firewall, confirm its rules cover this flaw and that it is actually inspecting traffic to the upgrade path. If you rely on a hosting provider, ask them directly whether wp-content/upgrade is reachable from the web and whether PHP executes there. A vague answer is an answer.

Finally, take a hard look at your update cadence. This bug is a reminder that the update process is part of your attack surface, and that the hours right after a release are when attackers are most motivated. Patching quickly is still the right call. It just needs to happen on a server that is not handing strangers a running installer while it works.

The bottom line

A CVSS 8.1 race condition with a seconds long window sounds like the kind of thing you can schedule for next month. The attack data says otherwise. Someone is putting real effort into catching WordPress sites mid upgrade, and they are doing it at a scale of tens of thousands of attempts per day. This is bad, prioritize it. Patch to 7.1.4, block the staging directory, and check your logs before you assume you were not one of the sites they were watching.

MSP angle

Every client with a forgotten marketing site on cheap shared hosting just became a conversation about managed WordPress hardening, where you own patching, web server lockdown, and log review instead of hoping auto updates win a race. Package it with a one time compromise assessment for sites that sat unpatched over the past week and you have a concrete, time sensitive offer that sells itself.