WordPress 7.1.4 fixes core upgrade race that can lead to remote code execution, with attacks reported

TLDR

• WordPress 7.1.4, released 28 October, fixes a core update race condition that can lead to remote code execution.¹²
• Wordfence says attackers are polling for the flaw; exploitation must hit a period that lasted only seconds in lab tests.¹
• Sites should confirm they run 7.1.4 or their branch's patched release; backports reach versions back to 4.7.¹³

WordPress released 7.1.4 on 28 October as a security release, and its announcement lists a weakness in the upgrade process that can lead to remote code execution, reported by Umut Bayram.² Wordfence says the flaw affects WordPress Core 4.7 through 7.1.3, does not require an account on the site, and carries a CVSS score of 8.1 (High).¹ WordPress's own GitHub advisory says that during a core update using a complete package, WordPress 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.³ The fix was backported to all branches back to 4.7.³

Wordfence says the staged copy sits in a predictable directory beneath wp-content/upgrade and includes the WordPress installer.¹ It lists four conditions for an attack: a full-package update containing the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time before WordPress cleans up the temporary files.¹ It rates the attack complexity as high and says the staging directory normally stayed available for only seconds in lab environments, though repeated automated polling can improve an attacker's chances.¹ According to Wordfence, 7.1.4 randomises the staging directory, adds an index guard and prevents unsafe promotion of staged configuration data.¹ The same release fixes 22 vulnerabilities in total and updates the bundled root certificates after the eMudhra revocation.²⁵

On exploitation, Wordfence says it deployed a firewall rule on 28 October at 20:30 UTC, the first match arrived nine minutes later, and in the first 21 hours it recorded more than 18,500 requests targeting staged setup-config.php installer paths.¹ It adds that two of the largest sources polled small groups of sites for roughly 14.5 hours, and that not every request used the exact vulnerable path.¹ heise online repeats the 18,500 figure.⁶ The Hacker News reports that Wordfence said it blocked 62,969 attacks targeting the vulnerability over the past 24 hours.⁴ SecurityWeek reports that Wordfence has not reported successful compromises.⁵

On updating, WordPress.org says sites that support automatic background updates will begin the update automatically, and that backports were in progress and would ship as they became ready.² Wordfence says most sites should receive the release through automatic background updates but recommends checking Dashboard > Updates rather than assuming it completed.¹ heise online says only an upgrade using the full core package is vulnerable and that WordPress's default automatic update mechanism is part of why attacks have any chance of succeeding.⁶ For sites that stayed unpatched, Wordfence advises looking for unexpected requests to PHP files beneath wp-content/upgrade, unfamiliar administrator accounts, unexpected plugins and PHP files.¹

The sources differ on the CVE. The Hacker News, SecurityWeek and heise online each say no CVE identifier had been assigned or was available at the time of reporting.⁴⁵⁶ Wordfence's post lists CVE-2026-119977 for the flaw, while the GitHub advisory leaves the CVE ID field empty and labels its severity Low.¹³

Why it matters: the flaw sits in the update path itself, and Wordfence's own advice is to verify that the patched release is installed rather than assume the automatic update completed.¹