WordPress 7.1.4 core update race (GHSA-4w3m-c66w-69mg): unauthenticated code execution during upgrades, now under attack

What happened

On 28 October 2026, WordPress released 7.1.4, a security release that also fixes a series of stored XSS bugs and updates the bundled root certificates for the eMudhra revocation (WordPress). The most serious is a race condition in the core update process, reported by Umut Bayram.

During a core update that uses a complete package, WordPress extracted the new files into a predictable directory inside the web-served upgrade folder. An unauthenticated attacker who wins a race against that extraction could reach remote code execution. Every branch from 4.7.0 to 7.1.3 is affected (GitHub advisory). Wordfence explains that the extracted copy under wp-content/upgrade includes the WordPress installer (The Hacker News).

WordPress rates the issue Low and lists no CVE (GitHub advisory). The Hacker News reports a CVSS score of 8.1. The attacker needs all of these, per Wordfence: a full-package core update that contains the installer files, public web and PHP access to the staging folder, a predictable or discovered staging path, and enough time before WordPress deletes the temporary files. In lab tests the window lasted seconds (The Hacker News). 7.1.4 randomises the staging directory name, adds an index guard and stops staged configuration data from being promoted unsafely (SecurityWeek).

Attackers are trying. Wordfence saw the first match for its new firewall rule nine minutes after deploying it. It recorded more than 18,500 requests for staged setup-config.php installer paths in the first 21 hours (SecurityWeek), and 62,969 blocked attacks in 24 hours. Two of the largest sources polled small groups of sites for about 14.5 hours, which Wordfence says fits an attempt to catch the update window (The Hacker News). No successful compromise has been reported.

Am I affected?

Any site on 4.7.0 to 7.1.3 that has not received the fixed release for its branch is affected. Check each site:

# With WP-CLI, from the site root
wp core version

# Without WP-CLI
grep "wp_version =" wp-includes/version.php

Fixed releases by branch (GitHub advisory): 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34 and 4.7.39.

Check whether automatic background updates are switched off in wp-config.php:

grep -nE "AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE" wp-config.php

Look for probing and possible success in your web server access logs:

grep -E "wp-content/upgrade/|setup-config\.php" /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

A 200 response to a setup-config.php or other PHP path under wp-content/upgrade/ is worth investigating. Probes that got 404 or 403 are noise.

What to do now

1. Update every site to 7.1.4 or the fixed release for its branch. Sites with automatic background updates update themselves; confirm they did (WordPress).
2. Deny web access to wp-content/upgrade/ at the web server. WordPress uses that folder through the file system, not over HTTP, and the attack depends on public web and PHP access to it. Doing this before you run the update also closes the window during the update itself. For nginx:

location ^~ /wp-content/upgrade/ { deny all; }

For Apache, in the virtual host:

<Directory "/path/to/site/wp-content/upgrade">
    Require all denied
</Directory>

3. Hunt with the log search above. For any site that returned 200 for those paths, check for administrator accounts, plugins or PHP files you did not add (The Hacker News).
4. Re-enable automatic minor updates on sites where they were turned off, or bring those sites into a patch process that applies security releases within a day.

Sources

• GitHub advisory GHSA-4w3m-c66w-69mg
• WordPress 7.1.4 security release
• The Hacker News: WordPress RCE flaw draws nearly 63,000 attack attempts
• SecurityWeek: fresh WordPress vulnerability in attackers’ crosshairs