WordPress 7.1.4 update race RCE: Wordfence counts 18,500 installer path requests in 21 hours, no CVE yet

Nine minutes after the rule went live: the first match, 3 hours 26 minutes after the release

WordPress published its 7.1.4 announcement at 17:13:02 UTC on 28 October 2026, a time taken from the page's own metadata. Wordfence says it deployed a firewall rule for the most serious flaw in that release at 20:30 UTC, and that "The first match for our new firewall rule arrived nine minutes after deployment." That puts the first match at about 20:39 UTC, 3 hours 26 minutes after the announcement (derived from the two stated times and the page time). Over the first 21 hours Wordfence says it recorded more than 18,500 requests aimed at staged installer paths for setup-config.php, which is at least about 880 an hour, or about 15 a minute (derived).

Those are requests that matched one vendor's rule. They are not a count of sites, of successful attacks or of compromises. SecurityWeek, whose report of 30 October is the first coverage this briefing found, writes: "Wordfence has not reported successful compromises." No CVE identifier has been assigned that this briefing could find, and CISA's catalogue of known exploited vulnerabilities holds no entry for it (both checked at 13:59 UTC on 30 October). Wordfence can count only requests that match a rule it had already deployed, so anything sent before 20:30 UTC, and anything sent to a site without the rule, is outside the figure.

This briefing reads the primary records rather than the coverage of them: Wordfence's own post, WordPress's release announcement and its HelpHub page for 7.1.4, the releases list on wordpress.org, the WordPress source files at the 7.1.3 and 7.1.4 tags, and, as a separate analysis, Patchstack's post of 28 October. The Wordfence page answers a plain request with a bot challenge, which this briefing did not try to pass. The full text of the post was read instead from Wordfence's public RSS feed, where it appears as a full content item published at 21:58:44 UTC on 29 October. Everything was read from 13:56 UTC on Friday 30 October 2026, and the volatile pages were read again at 14:13 UTC.

Interests, stated once. Wordfence sells a WordPress firewall and gets visibility from the finding. Its rule reached paying customers on 28 October and reaches Free users on 27 November. Patchstack sells security products and a vulnerability database, and Pantheon sells managed WordPress hosting. Each is quoted for what it says, not endorsed.

What the race is, and what an attacker has to win

WordPress's announcement lists the flaw first among its security fixes as "A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window". HelpHub words it as "A race condition during core updates that could lead to remote code execution". Neither page says more. The detail comes from Wordfence, which titles the entry as an unauthenticated upgrade window remote code execution, and from the source code itself.

Wordfence's account is short. During a core update that uses a complete WordPress package, affected versions unpack the new files into a predictable directory beneath wp-content/upgrade. That temporary copy includes the WordPress installer. Because the directory is reachable over the web on many servers, an unauthenticated attacker who requests the installer at the right moment can interact with the staged copy and progress to PHP code execution. The attacker must also "hit a very narrow window while WordPress is unpacking a complete Core update". Wordfence's lab observation is that "that window was observed to last only seconds".

Wordfence lists four things the attacker needs, and calls the attack complexity high:

Complexity high describes how hard the race is to win, not how rare the attempts are. Wordfence says a single request is unlikely to succeed but that repeated automated polling improves the odds, and its telemetry is of exactly that: two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours.

Zoom

What does the fix change? Wordfence says WordPress 7.1.4 addresses the issue by "randomizing the staging directory, adding an index guard, and preventing unsafe promotion of staged configuration data". The two source files that WordPress's HelpHub page lists as revised match that description. In class-wp-upgrader.php, the working directory name now gets 16 random characters appended, the cleanup keeps index.php in the upgrade directory instead of deleting it, and an index.php is created if missing. In update-core.php, wp-config.php joins the list of files that are never copied out of the working directory. That reading of the code is this site's, checked against Wordfence's three phrases; Patchstack's separate analysis reads it the same way. The changed lines are quoted in the Technical details section.

Patchstack adds three claims that Wordfence and WordPress do not make: that the sink dates back to WordPress 2.8, that the extracted copy loads WordPress from its own files, and that for this reason "A PHP firewall cannot block it." These rest on one vendor's reading and were not tested here. The last one matters, and it is set against Wordfence's advice in the section on labels below.

Affected and fixed versions, and the backports line that disagrees with the list

Wordfence gives the affected range as WordPress Core 4.7.0 to 7.1.3, with 25 patched versions from 4.7.39 up to 7.1.4 (printed exactly in the Technical details section). Counting rows on the wordpress.org releases list, all 25 of those versions carry the date 28 October 2026 (derived by counting). The previous releases were 7.1.3 on 6 October and 4.7.38 on 6 October, so 7.1.4 came 22 days after 7.1.3 (derived).

HelpHub states, for each branch from 7.0 down to 4.7, how many of the 22 vulnerabilities in the release affect it, and names the release that contains the fixes. Those counts are across all 22, not for this flaw: 7.0 and 6.9 are affected by all 22, and 4.8 and 4.7 by 2 of 22. HelpHub also says "WordPress 4.6 and earlier no longer receive security updates." Sites on 4.6 or earlier have no fixed release to move to within their branch.

The announcement text and the lists do not conflict on facts: the lists show every backport shipped on 28 October. The stale sentence is a reminder to check the version actually running on a site rather than trusting any one page. WordPress also says 7.2 Beta 3 contains all applicable fixes, and that the next major release, 7.2, is planned for 8 December.

Do automatic updates close the exposure? They deliver the fix, and may run the exposed step

WordPress says: "If you have sites that support automatic background updates, the update process will begin automatically." Wordfence says: "Most WordPress sites should receive the security release through automatic background updates", and adds: "we strongly recommend checking your site rather than assuming the update completed".

Read together with the mechanism, there is a point neither page makes. The flaw is in the code that unpacks a core update. A site on 7.1.3 runs 7.1.3's code to install 7.1.4. So the update that delivers the fix is itself run by the unfixed code, and if that update is a full package update, it is the very window the attack needs. That is an inference from the mechanism and the code, not a statement in any primary. It means automatic updates deliver the fix, but they do not make the window harmless while they run.

Whether a given site's update is a full package update is not stated in any primary. The 7.1.4 upgrader code chooses in a fixed order: a partial package if the update service offers one for the installed version and the site is not being reinstalled, then a new bundled package, then a no content package, and otherwise the full package. The service's offer for 7.1.4 is not in any source read. One more fact points the same way: the 32 revised files on HelpHub do not include wp-admin/setup-config.php, so a partial package from 7.1.3 would not obviously carry the installer. That too is an inference, because no package was opened. It is a reason the exposure may be narrower than "every site", and no reason to leave a site unpatched. Reinstalls, jumps across several versions, partial packages rejected by the integrity pre check, and tools that fetch the full zip are all places a full package could appear; none is established for any site here.

If automatic updates are off, because a site is deliberately pinned, managed by a pipeline, or has file modification disabled, nothing will happen by itself and the site stays on the unfixed code until someone updates it. Patchstack's advice for the interim, to deny web access to wp-content/upgrade/ at the web server and to check that the directory cannot be listed, is the only mitigation in the record that does not depend on a firewall product. No primary prints a server setting for it. Example settings are in the Technical details section, labelled derived and untested.

What Wordfence observed, and what it cannot see

Two timing facts follow from the stated times. The rule went live 3 hours 17 minutes after the announcement (derived: 17:13:02 to 20:30 UTC), so the earliest request Wordfence could count was that late. And if the 21 hours are counted from the rule going live, which the post does not say, they end at about 17:30 UTC on 29 October (derived), while the post was published at 21:58:44 UTC, so the figure would be a snapshot already about 4 hours 28 minutes old when it appeared (derived). SecurityWeek's phrase that exploitation began within hours of patching is consistent with a first match about 3 hours 26 minutes after the release, but it is Wordfence's rule time, not an observed start of attacks, that sets that lower bound. Attackers who tried earlier would be invisible to this count.

Zoom

No CVE, no catalogue entry, and who set the 8.1

The 8.1 is Wordfence's number, printed in its own post, and is the only score in the record. Where a score appears, it belongs to whoever assigned it. A listing in CISA's catalogue, if it comes, would be the strongest public statement of exploitation, and it would also start a federal remediation clock. Neither exists as of the time of reading, and this paragraph is time stamped for that reason.

Context from earlier briefings on this site: the four point releases 7.1.1 to 7.1.4 are dated 17 September, 22 September, 6 October and 28 October on the releases list, 41 days from first to last (derived). The earlier core flaw CVE-2026-87902 is covered in the briefing on the 7.1.2 release and, once exploitation was reported, in the follow up on what to search for. That flaw had a CVE and a catalogue listing. This one has neither yet, and the public record rests on a single vendor's telemetry.

Stated and not stated: the record, line by line

A detail on the Pantheon line: its page says "However, customers need to update their sites as soon as possible." That is a host with a product to sell telling its own customers that platform rules are not a substitute for the update. It is one host.

The differences appear to be grouping rather than disagreement: several items bundle multiple reports, and one is a certificate update rather than a vulnerability. The point for a reader is that the race condition is the one item of the set that Wordfence and Patchstack both describe as needing no account, whichever way the set is counted.

Six labels that sound like controls

Zoom

The firewall line deserves one more sentence. Two vendors that sell security products give different advice about the same request: Wordfence says run its firewall in Extended Protection mode so it runs before the PHP file is reached, and Patchstack says block it at the web server. Both agree on the one control that does not depend on either: install the fixed release.

Technical details

What the primaries publish is thin: no IP addresses, no user agents, no hashes, no request strings and no log lines. Wordfence prints two paths and a version range, and the WordPress source files show the fix. Everything below is copied from those pages or files. Where this site wrote the block, it says so. Nothing here is a working exploit, and the staged paths are named only as far as Wordfence and Patchstack name them.

First, the entry exactly as Wordfence's post prints it. Use it to check a site's version against the patched list for its branch.

WordPress Core 4.7.0 - 7.1.3 - Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution
8.1
CVSS Rating
8.1 (High)
Affected Version(s)
Various
Patched Versions
4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11, 7.0.8, 7.1.4

Second, the paths the primaries name. Wordfence names the directory and the installer file its firewall rule targets. Patchstack gives the full path of the installer inside a staged copy. A defender searches web server access logs for requests to PHP files beneath the upgrade directory, from 17:13 UTC on 28 October onward.

wp-content/upgrade
wp-content/upgrade/
setup-config.php
wp-admin/setup-config.php

Third, the fix. These are the changed lines in class-wp-upgrader.php between the 7.1.3 and 7.1.4 tags of the official WordPress development repository on GitHub. A unified diff: lines starting with a plus sign were added, a minus sign removed. The working directory name now ends in 16 random characters, the cleanup skips index.php, and the directory and its index are created if missing.

@@ -341,6 +341,21 @@
 		}
 
 		return $download_file;
+	}
+
+	/**
+	 * Builds an unpredictable name for the directory a package is unpacked into.
+	 *
+	 * @since 7.1.4
+	 *
+	 * @param string $package The full local path or URI of the package.
+	 * @return string The directory name, without a path.
+	 */
+	private function get_working_dir_name( $package ) {
+		// Strip off any .tmp or .zip suffixes.
+		$name = basename( basename( $package, '.tmp' ), '.zip' );
+
+		return $name . '-' . wp_generate_password( 16, false );
 	}
 
 	/**
@@ -366,17 +381,33 @@
 
 		$upgrade_folder = $wp_filesystem->wp_content_dir() . 'upgrade/';
 
-		// Clean up contents of upgrade directory beforehand.
+		// Clean up contents of upgrade directory beforehand, keeping its index.php.
 		$upgrade_files = $wp_filesystem->dirlist( $upgrade_folder );
 		if ( ! empty( $upgrade_files ) ) {
 			foreach ( $upgrade_files as $file ) {
+				if ( 'index.php' === $file['name'] ) {
+					continue;
+				}
+
 				$wp_filesystem->delete( $upgrade_folder . $file['name'], true );
 			}
 		}
 
-		// We need a working directory - strip off any .tmp or .zip suffixes.
-		$working_dir = $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' );
+		/*
+		 * The upgrade directory is web-served. Keep it from being listed, as core does
+		 * for wp-content and its plugins and themes directories, so the name of the
+		 * working directory created below cannot be discovered from a directory index.
+		 */
+		if ( ! $wp_filesystem->is_dir( $upgrade_folder ) ) {
+			$wp_filesystem->mkdir( $upgrade_folder, FS_CHMOD_DIR );
+		}
+		if ( ! $wp_filesystem->exists( $upgrade_folder . 'index.php' ) ) {
+			$wp_filesystem->put_contents( $upgrade_folder . 'index.php', "<?php\n// Silence is golden.\n", FS_CHMOD_FILE );
+		}
 
+		// We need a working directory.
+		$working_dir = $upgrade_folder . $this->get_working_dir_name( $package );
+
 		// Clean up working directory.
 		if ( $wp_filesystem->is_dir( $working_dir ) ) {
 			$wp_filesystem->delete( $working_dir, true );

The second changed file, update-core.php, adds wp-config.php to the files that are never copied out of the working directory.

@@ -1545,8 +1545,9 @@
 	/*
 	 * Don't copy wp-content, we'll deal with that below.
 	 * We also copy version.php last so failed updates report their old version.
+	 * Never copy a wp-config.php, which could have been written to the working directory.
 	 */
-	$skip              = array( 'wp-content', 'wp-includes/version.php' );
+	$skip              = array( 'wp-content', 'wp-includes/version.php', 'wp-config.php' );
 	$check_is_writable = array();
 
 	// Check to see which files don't really need updating - only available for 3.7 and higher.

Fourth, why "which package" matters. This is the part of class-core-upgrader.php at the 7.1.4 tag that picks the package for a core update. It is unchanged context, not part of the fix. It shows the order: rollback, partial, new bundled, no content, and the full package as the last resort.

		/*
		 * If partial update is returned from the API, use that, unless we're doing
		 * a reinstallation. If we cross the new_bundled version number, then use
		 * the new_bundled zip. Don't though if the constant is set to skip bundled items.
		 * If the API returns a no_content zip, go with it. Finally, default to the full zip.
		 */
		if ( $parsed_args['do_rollback'] && $current->packages->rollback ) {
			$to_download = 'rollback';
		} elseif ( $current->packages->partial && 'reinstall' !== $current->response && $wp_version === $current->partial_version && $partial ) {
			$to_download = 'partial';
		} elseif ( $current->packages->new_bundled && version_compare( $wp_version, $current->new_bundled, '<' )
			&& ( ! defined( 'CORE_UPGRADE_SKIP_NEW_BUNDLED' ) || ! CORE_UPGRADE_SKIP_NEW_BUNDLED ) ) {
			$to_download = 'new_bundled';
		} elseif ( $current->packages->no_content ) {
			$to_download = 'no_content';
		} else {
			$to_download = 'full';
		}

Fifth, commands and server settings that this site wrote. They are derived, not published by any primary, and were not run here. Test them on a staging copy first. One design point follows from the 7.1.4 diff above: the cleanup deletes everything in the upgrade directory except index.php, so a deny file placed inside the directory would be removed by the next update. Put the rule in the server or virtual host configuration instead.

# Which core version is running (WP-CLI)
wp core version

# Compare core files with the official checksums (WP-CLI)
wp core verify-checksums

# Patchstack says the directory holds only index.php between updates; anything else deserves a look
ls -la wp-content/upgrade/

# Web server access logs: requests for PHP files beneath the upgrade directory (adjust the log path)
grep -E "wp-content/upgrade/.*[.]php" /var/log/nginx/access.log*

# Apache 2.4, in the virtual host, not in a file inside the upgrade directory
<LocationMatch "^/wp-content/upgrade/">
    Require all denied
</LocationMatch>

# nginx, inside the server block
location ^~ /wp-content/upgrade/ { deny all; }

What to do, in the order worth doing

What could not be verified

• Wordfence page. The post and its vulnerability entry return a bot challenge to a plain request. This briefing did not attempt to pass it. The post was read in full from Wordfence's public RSS feed, which carries the full text; the vulnerability entry page was not read, so the CVSS vector is not known.
• CVE.org. A search by name needs a browser and an identifier. NVD, which mirrors CVE records, was queried instead.
• Package type. No primary says which package the update service offered for 7.1.4. The reading in the automatic updates section is an inference.
• Counts. No source gives the number of vulnerable sites, sites with a reachable upgrade directory, or compromises.
• Patchstack's claims. The 2.8 origin and the statement that a PHP firewall cannot block the request are one vendor's reading, not tested here.
• The Wordfence Extended Protection page was not read, so what that mode does is as Wordfence summarises it in the post.

The question that exposes the gap

Which of your sites ran a core update between 17:13 UTC on 28 October and now, was the update a full package, was wp-content/upgrade reachable from the internet while it ran, and do your logs go back far enough to say who asked for it?

Key facts