WordPress Core < 7.1.4 - Unauthenticated Upgrade-Window RCE Under Active Attack

WordPress Core before 7.1.4 contains a high-severity unauthenticated race condition in the core update process. Automated exploitation attempts began shortly after release; update and block public access to wp-content/upgrade/.

WordPress Core versions before 7.1.4 contain a high-severity race condition in the core update process that can expose a temporary, runnable WordPress installation to unauthenticated requests. Wordfence reports more than 18,500 exploit requests during the first 21 hours after the security release. These are exploitation attempts, not confirmation that every targeted site was compromised.

Table of Contents

Vulnerability summary

Product: WordPress Core
Affected: versions before 7.1.4; supported older branches require their corresponding October 28 security backport
Fixed: 7.1.4 and patched branch releases from 7.0.8 through 4.7.39
Attack class: unauthenticated race condition leading to remote code execution during a core update
Severity: High, CVSS 8.1 according to WPScan and Wordfence
CVE: no CVE identifier had been assigned at publication time
Exploitation: automated exploitation attempts observed after release; successful compromises have not been confirmed publicly

How the upgrade-window RCE works

During a core update, vulnerable WordPress versions extract the package beneath wp-content/upgrade/. The working directory name was predictable, and the cleanup process could remove the protective index.php. For a few seconds, a complete extracted WordPress package could therefore be reachable at a guessable web path.

The extracted package contains wp-admin/setup-config.php, which can run independently of the production site’s existing configuration. An unauthenticated attacker who reaches that file during the narrow update window can point the staged installer at infrastructure they control and gain PHP execution within the temporary installation.

Exploitation requires precise timing, a full core package containing the installer, and public web access to wp-content/upgrade/. That makes attack complexity high, but automated polling can repeatedly target the window created by scheduled or manual updates.

What WordPress 7.1.4 changes

WordPress 7.1.4 adds 16 random characters to the temporary extraction directory, recreates and preserves its protective index.php, and prevents wp-config.php from being copied from the working directory. The release also fixes multiple stored XSS, information-disclosure, denial-of-service, and authorization issues.

Patched releases are available for supported branches: 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. WordPress 4.6 and earlier no longer receive security updates and should be migrated to a supported release.

Observed exploitation activity

Wordfence deployed a firewall rule on October 28, 2026 and recorded the first matching request nine minutes later. It counted more than 18,500 requests targeting staged installer paths in the following 21 hours, with two major sources polling for roughly 14.5 hours. This is strong evidence of active attempts to catch the update race, but it does not establish that those requests produced successful compromise.

Immediate remediation

Update WordPress Core immediately to 7.1.4 or the patched release for the installed branch.
Deny public access to wp-content/upgrade/ at the web server. A PHP-based security plugin may not load when a request runs against the extracted copy, so enforce this outside WordPress.
Confirm directory listing is disabled and that PHP cannot execute inside the upgrade directory.
Review access logs around recent update times for staged setup-config.php requests and repeated polling.
Investigate matched requests before declaring the site clean. Updating removes the vulnerability but does not reverse a prior compromise.

Temporary web-server mitigation

Use these rules only after confirming they fit the server configuration. Keep the restriction after patching as defense in depth.

Apache

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

Nginx

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

Verification and detection

Confirm the running version and whether WordPress still offers a core update:

wp core version
wp core check-update

Review web-server logs for the clearest request indicator. Adjust the log path for the hosting environment:

grep -E 'wp-content/upgrade/.*/wp-admin/setup-config\.php' /var/log/nginx/access.log*
grep -E 'wp-content/upgrade/.*/wp-admin/setup-config\.php' /var/log/apache2/access.log*

Potential indicators include repeated requests to temporary upgrade paths, requests for staged wp-admin/setup-config.php, unexpected PHP files in or near the upgrade directory, unfamiliar administrator accounts, newly installed plugins or must-use plugins, unknown scheduled tasks, and modified site URL or administrator email options. Preserve logs and file timestamps before cleanup. If evidence suggests code execution, take the site out of service, restore from a known-clean backup, rotate WordPress, hosting, database, SFTP/SSH, and API credentials, and review every persistence point.