Attackers Are Trying to Catch WordPress Sites Mid-Update: The Race-Condition Flaw Fixed in 7.1.4, and a Checklist for Site Owners
A WordPress core flaw lets an attacker with no account run code on a server during the few seconds a full core update is unpacking. Version 7.1.4 fixes it, and Wordfence is already blocking tens of thousands of attempts. Here is who is exposed and what to check.
Most security bugs live in code that runs all the time. This one lives in a moment: the few seconds when WordPress is unpacking a full core update. The WordPress team fixed it on October 28 in version 7.1.4, and within hours attackers were hammering sites in the hope of catching that moment.
We based this rundown on The Hacker News’ report on the attack attempts, with extra detail from SecurityWeek’s coverage of the Wordfence findings.
The flaw at a glance
- What it is: a race condition in the WordPress core update process that can lead to remote code execution on the web server.
- Login needed: none. The attacker does not need an account on the site.
- Severity: rated high, with a CVSS score of 8.1. Attack complexity is high because the timing window is short.
- Versions affected: WordPress 4.7 through 7.1.3.
- Fixed in: 7.1.4, with fixes also backported to older branches going back to 4.7.
- CVE: none assigned at the time of reporting.
Why the update itself was the weak spot
When WordPress installs a full-package core update, it first unpacks the new files, including the WordPress installer, into a staging folder under wp-content/upgrade. On affected versions that folder had a predictable location, and on many servers it can be reached from the web. An attacker who requests the staged installer at exactly the right instant can work with that temporary copy and move on to running PHP code on the server.
Wordfence, whose researchers described the bug, lists four things that all have to line up for an attack to succeed:
- A full-package update that includes the installer files.
- Public web and PHP access to the staging folder.
- A staging path the attacker can predict or discover.
- Enough time to finish before WordPress deletes the temporary files.
In lab testing the window lasted only seconds. Attackers are making up for that with persistence: Wordfence said two of the busiest sources repeatedly polled small groups of sites for about 14.5 hours, while others cycled through variations of staging folder and version names.
The numbers so far
- Wordfence said its first firewall rule match arrived nine minutes after the rule went live.
- In the first 21 hours it recorded more than 18,500 requests aimed at staged setup-config.php installer paths.
- Over a 24-hour period, it said it blocked 62,969 attacks targeting the flaw, though not every request hit the exact vulnerable path.
- Wordfence has not reported any successful compromises.
What 7.1.4 changes
The fix randomizes the staging folder name, adds an index guard and stops staged configuration data from being promoted unsafely. The same release patches 22 security issues in total, including several cross-site scripting bugs, an unauthenticated information disclosure bug and an authorization weakness, and it refreshes the bundled root certificates to reflect the recent eMudhra revocation.
Checklist for site owners
- Confirm your site is on WordPress 7.1.4, or the patched release for the older branch you run.
- Ask your host or web team to look for requests to PHP files under wp-content/upgrade in recent access logs.
- Review the user list for administrator accounts nobody recognizes.
- Look for plugins or PHP files that were not installed by your team.
- If you rely on automatic updates, confirm they actually completed rather than assuming they did.
What this means for your company
Your website is often the most public piece of technology your business owns, and this flaw is a reminder that even routine maintenance can open a brief door. Know who is responsible for updating your site, how quickly they act on security releases, and who would notice a strange administrator account or a file that should not be there. A web application firewall and regular log review are inexpensive ways to add a second line behind prompt patching.
Not sure whether your WordPress site is current, or whether anyone is watching its logs? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
