WordPress 7.1.4 Fixes an Unauthenticated RCE Race During Core Updates

Timing: WordPress released the fix on 28 October 2026. We publish on 30 October, two days later. Attack attempts started within hours of the release.

What happened

An attacker with no account could run PHP code on a WordPress site during a core update. WordPress fixed it in 7.1.4 on 28 October. The same fix shipped for every branch back to 4.7.39.

The release post calls it "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window". Umut Bayram of Picus Security reported it.

There is no CVE. GitHub advisory GHSA-4w3m-c66w-69mg covers it, published on 29 October.

How the attack works

During a core update with a complete package, WordPress unpacks the new files into a folder under wp-content/upgrade/. That folder is served by the web server like any other.

Before 7.1.4:

• The folder name was predictable. It came from the package file name.
• The protective file was deleted. The cleanup step removed the index.php that stops the folder from being listed.
• A full WordPress copy sat there. For a few seconds, it included the installer, wp-admin/setup-config.php.

An attacker who requests that installer in time can run it against a database they control. Wordfence says this leads to PHP code execution. The fix commit also says a wp-config.php "could have been written to the working directory" and then copied into the live site.

What the fix changes

The fix is commit e7b33f536d on the 7.1 branch. It touches two files:

• Random folder name. The working folder gets 16 random characters added.
• index.php stays. The cleanup keeps it, and recreates it if missing.
• No wp-config.php copy. A core update never copies wp-config.php out of the working folder.

Severity: two different labels

• Wordfence scores it CVSS 8.1 (High). It stresses high attack complexity.
• Patchstack also rates the attack complexity high (AC:H). It says it "would not call it practical to exploit".
• The GitHub advisory labels it "low", with no CVSS vector.

The impact is code execution. The hard part is the timing.

What attackers are doing

Wordfence deployed a firewall rule on 28 October at 20:30 UTC. The first hit came nine minutes later.

• More than 18,500 requests targeted staged setup-config.php paths in the first 21 hours.
• Two large sources polled small groups of sites for about 14.5 hours. That fits trying to catch an update window.
• Others tried many variations of folder and version names.

Wordfence notes that not every request used the exact vulnerable path. It does not report a confirmed takeover.

When a site is at risk

All of these must be true:

1. A core update with a complete package is running. Automatic background updates count.
2. wp-content/upgrade/ is reachable over the web and runs PHP.
3. The attacker knows or guesses the folder name.
4. The attacker wins the race in a window that lasted seconds in Wordfence's lab.

Sites that set DISALLOW_FILE_MODS do not run the in-place updater. In our reading, they should not be exposed to this bug. WordPress does not say this.

Important: the update to 7.1.4 is still unpacked by your current, unpatched code. That last update can open the window one more time. Block the folder first, then update.

What is confirmed

• The bug and the fix, from WordPress, the GitHub advisory and the commit.
• Affected range 4.7 to 7.1.3, with fixed versions for every branch (table below).
• Attack attempts in the wild, from Wordfence telemetry.

What is not confirmed

• A successful compromise. Nobody has reported one.
• A CVE. None is assigned. The advisory lists cve_id as empty.
• CISA KEV. Not listed. KEV tracks CVEs, and there is none.
• A public PoC. We searched GitHub, X, Exploit-DB, Nuclei templates and Metasploit pull requests on 30 October. We found no public exploit for this bug. The polling shows attackers have automated the hunt for the window. That is not the same as a working public exploit.

Fixed versions

From the WordPress 7.1.4 documentation page. The count is how many of the release's 22 issues affect each branch.

WordPress 4.6 and older get no fix. Only the latest version is actively supported.

What to do

1. Block /wp-content/upgrade/ at the web server. Do it before you update. WordPress only needs filesystem access to that folder, not web access.
2. Update. Install 7.1.4 or your branch's fixed version. Then check Dashboard → Updates. Don't assume the auto-update ran.
3. Don't rely on a PHP firewall. The staged copy boots from its own files, so plugin firewalls never load. Wordfence users need Extended Protection for its rule to apply. Its free tier gets the rule on 27 November.

Nginx, inside the site's server block. The ^~ prefix makes it win over the PHP location:

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

Apache 2.4, in the virtual host:

<Directory "/var/www/example/wp-content/upgrade">
    Require all denied
</Directory>

Adjust the path. Do not put a .htaccess file inside wp-content/upgrade/. The old cleanup step deletes everything in that folder before each unpack. If you can only use .htaccess, put this in the site root, above the WordPress block:

RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]

Then check that https://your-site/wp-content/upgrade/ returns 403.

What to check in logs

If your site ran an update before you patched, look for:

• Requests to setup-config.php or install.php under /wp-content/upgrade/. Any 200 response is a red flag. Note the time and compare it with your update times.
• A changed wp-config.php. Check DB_HOST, DB_NAME and DB_USER. A database host you don't recognize points to a takeover.
• New administrator accounts you did not create.
• Unexpected plugins or PHP files, including under wp-content/upgrade/.

The other 21 fixes

The release fixes 22 issues in total. Most of the other 21 need a logged-in user, usually a Contributor or higher. They are mainly stored XSS, many in the Interactivity API and in blocks. One more needs no account: unpublished Customizer changesets could be read by anonymous visitors. The release also updates the bundled root certificates after the eMudhra revocation.

Three weeks earlier, WordPress 7.1.3 fixed seven issues. 7.1.4 includes those fixes too.

ThreatWire did not run any exploit. We do not publish attack payloads.

Sources: the WordPress 7.1.4 release post and documentation page, GitHub advisory GHSA-4w3m-c66w-69mg, commit e7b33f536d, Wordfence and Patchstack. Links are in the references list.