WordPress 7.1.4 Fixes Update Flaw Attackers Probe

WordPress 7.1.4, released on 28 October, closes a flaw in the software’s own update process that can let an attacker with no account run code on a website’s server, and attackers are already trying to use it. WordPress urged owners in its release announcement to “update your sites immediately”, and the security firm Wordfence said a day later that “threat actors are already actively attempting to exploit it”.

The first thing to do is simple: open Dashboard > Updates and confirm that the site shows WordPress 7.1.4, or the patched release for the older branch it runs. Wordfence has not reported any successful compromise, and the attack is hard to pull off. But the fix only protects a site once it is installed, and Wordfence warns against assuming that an automatic update has gone through.

In brief

WordPress 7.1.4 and matching releases back to 4.7.39 fix a flaw that can lead to remote code execution while a site installs a core update.
Wordfence says attackers began probing for it within minutes of its firewall rule going live; it has reported no successful attacks.
No CVE has been assigned, and WordPress and Wordfence rate the severity very differently.

How the WordPress 7.1.4 update flaw works

The bug was found and reported by the researcher Umut Bayram. WordPress’s security advisory on GitHub, GHSA-4w3m-c66w-69mg, published on 29 October, describes it in two sentences. During a core update that uses a complete package, older versions “extracted the new files to a predictable directory inside the web-served upgrade folder”, and “an unauthenticated attacker who wins a race against that extraction could reach remote code execution.”

In plain terms, a site is only exposed for the brief moment while it unpacks a full update, and only if an attacker reaches the temporary files before WordPress tidies them away. Wordfence says the files sit under wp-content/upgrade, which many servers make reachable from the web. “In lab environments, the vulnerable staging directory normally remained available for only seconds,” the firm wrote, so a single attempt is unlikely to work. Repeated, automated attempts improve the odds.

According to Wordfence, the fix randomises the staging directory, adds an index guard and stops unsafe promotion of staged configuration data. Every version from 4.7.0 to 7.1.3 is affected. The advisory lists patched releases for every branch, including 7.0.8, 6.9.11, 6.8.12 and 4.7.39, and all of them are now on WordPress’s download pages. Wordfence notes that WordPress 4.6 and earlier no longer receive security updates.

What Wordfence has seen since the patch

Wordfence pushed a blocking firewall rule at 20:30 GMT on 28 October, about three hours after the release. “The first match for our new firewall rule arrived nine minutes after deployment,” it said. In the first 21 hours it recorded more than 18,500 requests aimed at the staged installer files. Two of the largest sources “repeatedly polled small groups of sites for roughly 14.5 hours”, which Wordfence says is consistent with trying to catch the brief update window.

The firm is careful about what this proves. “Not every request used the exact vulnerable path,” it noted, though it concluded that attackers “quickly understood the race condition”. It gives no count of sites breached, and nothing in the WordPress or Wordfence material says any site has been.

Checking your site after WordPress 7.1.4

WordPress says sites that support automatic background updates will start the update on their own. Owners who manage updates by hand, or who have switched automatic core updates off, should update now. For anyone who has not, the advice from both sources comes down to a short list:

Confirm the version under Dashboard > Updates: 7.1.4, or the patched release for your branch.
If a site runs 4.6 or earlier, move it to a supported release, since those versions get no security updates.
A firewall is no substitute for the patch. Wordfence says its rule “does not replace installing the security update”, and users of its free plan only receive the rule on 27 November.
If a site stayed unpatched, look for PHP files you did not put beneath wp-content/upgrade, unfamiliar administrator accounts and unexpected plugins.

The WordPress security release also fixes a long list of other bugs, which Wordfence says WordPress’s detailed documentation puts at 22 vulnerabilities. They include several stored cross-site scripting flaws, a way for unauthenticated visitors to find unpublished Customizer changes, and a refresh of bundled root certificates after the eMudhra revocation. Two of the scripting bugs were reported by the AI company Anthropic. Wordfence says many of the remaining flaws need a logged-in Contributor, Author or Editor account to exploit.

A low label understates an update flaw under active probing

The most striking detail is the gap in how the flaw is rated. WordPress’s GitHub advisory labels its severity “Low” and lists no CVE. Wordfence scores it 8.1, or “High”, on the standard CVSS scale. Both can be defended. The attack depends on winning a race that lasts seconds, which keeps the odds of success low, but the reward for winning is the ability to run code on the server, without an account. Anyone who triages patches by a severity label or a CVE feed could easily have set this one aside, at the very moment Wordfence was logging thousands of requests aimed at it.

The second lesson is about where the weakness sits. It is not in a plugin or a theme, but in the update mechanism that site owners rely on to stay safe, and the exposure opens precisely when a site is doing the right thing by updating. That makes it a cousin of the stolen UpdraftCentral keys TSN reported last week, where a trusted maintenance channel became the way in.

Drupal took a similar approach this week when it warned that a Commerce Core flaw was being exploited before the CVE system had caught up. The pattern is the opposite of TeamViewer’s recent fix, which came with no reports of exploitation. For WordPress owners the practical point is the same either way: the vendor’s own notice and security researchers’ telemetry moved faster than the CVE system, and checking the installed version beats trusting that an update ran.

What to watch next is whether a CVE is assigned, whether WordPress revises its severity label, and whether Wordfence or WordPress report any confirmed compromise.