WordPress Core 7.1.4 Fixes an Unauthenticated Upgrade-Window Race RCE (CVE-2026-119977). Update and Block wp-content/upgrade/

TL;DR: WordPress 7.1.4 came out on 28 October 2026, along with fixed releases for every branch back to 4.7. Among its fixes is a race condition in the core update process. WordPress says it "could lead to remote code execution" by an unauthenticated attacker (GHSA-4w3m-c66w-69mg). WordPress rates the issue Low. Wordfence, the CVE Numbering Authority (CNA) that assigned CVE-2026-119977, scores it CVSS 3.1 8.1 (High) with high attack complexity (cve.org). Wordfence says attackers began polling for the vulnerable path within hours of the release. No successful compromise has been reported. What to do: confirm every WordPress site is on 7.1.4 or the fixed release for its branch. Deny web access to wp-content/upgrade/ at the web server.

What lowers the urgency:

• The window lasts seconds. The flaw can only be hit while WordPress is unpacking a complete core update package. Wordfence says that in lab environments the vulnerable directory "normally remained available for only seconds" (Wordfence). Patchstack scored it AC:H and says it "would not call it practical to exploit" (Patchstack).
• No confirmed compromises. Wordfence reports exploitation attempts, not successful attacks. SecurityWeek notes that "Wordfence has not reported successful compromises" (SecurityWeek).
• Most sites update themselves. WordPress says that on sites that support automatic background updates, "the update process will begin automatically" (WordPress 7.1.4).
• Not in CISA KEV. CVE-2026-119977 is not in CISA's Known Exploited Vulnerabilities catalog (catalogVersion 2026.10.30, checked 31 October 2026, 08:39 Cyprus time (UTC+2)).

What keeps it on the list: no account is needed, and attackers started probing within minutes of Wordfence's firewall rule going live. Wordfence also warns that "the malicious request goes directly to a PHP file without loading WordPress first". A WordPress security plugin may therefore never see the request.

Technical Information

WordPress describes the issue in its advisory:

"During a core update that uses a complete package, WordPress extracted the new files to a predictable directory inside the web-served upgrade folder. An unauthenticated attacker who wins a race against that extraction could reach remote code execution."

Wordfence explains why that matters. The temporary copy in wp-content/upgrade/ "includes the WordPress installer". The staging directory "is web-accessible on many servers". So an attacker "who requests the installer at precisely the right moment can interact with the staged WordPress copy and progress to PHP code execution." Patchstack's write-up names the installer file as wp-admin/setup-config.php. That file can run without the live site's configuration (Patchstack).

Wordfence lists four conditions for a successful attack:

1. A full-package core update, which contains the installer files.
2. Public web and PHP access to the staging tree under wp-content/upgrade/.
3. A predictable or discovered staging path.
4. Enough time to finish the attack before WordPress cleans up the temporary files.

Above all, the attacker has to win the race. Wordfence says this "narrow window makes a one-off request unlikely to succeed, but repeated automated polling can improve an attacker's chances."

What the fix changes. Wordfence says WordPress 7.1.4 fixes the issue "by randomizing the staging directory, adding an index guard, and preventing unsafe promotion of staged configuration data." Patchstack adds detail from the code. The working folder now gets 16 random characters added to its name. The index.php in the upgrade folder is kept and recreated if missing. wp-config.php is added to the files a core update never copies out of the working directory.

Severity: why the two ratings differ

• WordPress (vendor): "Severity Low" on GHSA-4w3m-c66w-69mg. No CVSS score published. The GHSA's CVE field reads "No known CVE". That was true when WordPress published it on 29 October, but it is now out of date: the CVE was assigned by Wordfence, not by WordPress, and published on cve.org on 31 October. WordPress has not yet updated its advisory.
• Wordfence (CNA for CVE-2026-119977, per the cve.org record): CVSS 3.1 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, weakness CWE-367 (time-of-check time-of-use race). Wordfence says its score "reflects the eventual impact", meaning code execution on the server, while "the attack complexity is high".
• NVD: the record is at status "Received" (31 October 2026, 08:16 Cyprus time). NVD has not published a score of its own.

Both ratings describe the same facts. The impact is serious if the race is won. Winning it is hard and depends on timing and server configuration. We use both ratings in this post and do not treat the flaw as an emergency for sites that are already patched.

Timeline

All times are Cyprus time (UTC+2).

• 28 October 2026: WordPress releases 7.1.4. The security fixes are backported to all branches back to 4.7 (WordPress HelpHub).
• 28 October 2026, 22:30: Wordfence deploys a firewall rule for paying customers. The first matching request arrives nine minutes later.
• 29 October 2026, 21:12: WordPress publishes GHSA-4w3m-c66w-69mg. France's CERT-FR publishes advisory CERTFR-2026-AVI-1420 for WordPress versions before 7.1.4. It lists remote code execution among the risks.
• 29 October 2026, 23:58: Wordfence publishes its analysis and reports active exploitation attempts.
• 31 October 2026, 07:33: CVE-2026-119977 is published on cve.org, assigned by Wordfence. WordPress's GHSA still reads "No known CVE" at the time of writing.

Exploitation activity

Wordfence says: "During the first 21 hours, we recorded more than 18,500 requests targeting staged setup-config.php installer paths." Two of the largest sources "repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window". Other sources "tested many staging-directory and version-name variations." Wordfence adds that "not every request used the exact vulnerable path."

In later reporting, The Hacker News says Wordfence blocked 62,969 attacks targeting the flaw over 24 hours (The Hacker News). We could not find the 62,969 figure in Wordfence's own post at the time of writing, so we cite it via The Hacker News. Neither source reports a confirmed site takeover. These are attempts, blocked or not. They do not show that attacks succeeded.

Affected Product Versions

From WordPress's GHSA-4w3m-c66w-69mg. The same ranges appear in the CVE-2026-119977 record.

WordPress also notes that "only the most recent version of WordPress is actively supported". The older-branch fixes are a courtesy. Sites on 4.6 or earlier get no fix and should move to a supported release.

Workaround and Mitigation

1. Deny web access to wp-content/upgrade/ at the web server, before you update. Patchstack advises: "Block it at the web server: deny access to wp-content/upgrade/, and check the directory is not listable." WordPress only needs filesystem access to that folder. Put the rule in the server or virtual host configuration, or in the site-root .htaccess. Do not put it in a file inside the upgrade folder. Patchstack notes that pre-7.1.4 versions delete everything in that folder before each unpack. (Doing this before you update is Rescana guidance. In our reading, the update to 7.1.4 is still unpacked by the old, unpatched code, so that last update can open the window once more.)
2. Update and confirm the update. Install 7.1.4 or the fixed release for your branch. Wordfence says most sites "should receive the security release through automatic background updates". It also recommends "checking your site rather than assuming the update completed". Use Dashboard > Updates to check, or check the version across your fleet with your management tooling.
3. Do not rely on a PHP-level firewall alone. Wordfence warns that this request bypasses WordPress. Sites using its plugin should enable Extended Protection. Wordfence Free users receive the rule only on 27 November 2026. Wordfence also says the firewall "does not replace installing the security update."
4. Check sites that were unpatched during an update. Wordfence advises looking for "unexpected requests to PHP files beneath wp-content/upgrade, unfamiliar administrator accounts, unexpected plugins, or PHP files you did not place there." Focus on the times when core updates ran.
5. Find the long tail. Look for sites with automatic updates turned off, sites on unsupported 4.6-or-earlier releases, and installs run by agencies or hosts outside your normal patch process. These are the sites most likely to stay exposed.

Indicators of Compromise

WordPress and Wordfence have not published network IoCs (IP addresses or hashes) for this flaw. Wordfence's behavioural signals are the ones in step 4 above: requests for staged setup-config.php or other PHP files under wp-content/upgrade/, especially repeated polling, plus unexpected admin accounts, plugins or PHP files. We found no IoCs from CISA, CERT-EU or CERT-FR.

Why this matters for vendor risk

WordPress runs much of the web, and that includes many vendors' marketing sites, customer portals, documentation hubs, careers pages and status pages. Agencies and hosting providers often run these sites for the vendor. They tend to sit outside the vendor's main patch and monitoring process. This flaw needs no account, but it does need an update in progress. Patching the flaw is simple. The harder questions are whether each site actually updated, whether the upgrade folder is reachable from the web, and whether anyone would notice a polling campaign timed to an update.

The severity gap (Low from WordPress, 8.1 High from the CNA) is one reason vendors may handle this differently. A vendor reading only the WordPress advisory may file it as routine. That is reasonable for sites that update themselves. It is not reasonable for sites with automatic updates off, sites on old branches, or sites that serve wp-content/upgrade/ to the internet. Questions to ask your vendors:

• Which of your public sites run WordPress, including sites run by agencies or hosts on your behalf?
• Are they all on 7.1.4 or the fixed release for their branch? Are any on 4.6 or earlier?
• Have you denied web access to /wp-content/upgrade/ at the web server?
• Did you review logs around recent core updates for requests to PHP files under wp-content/upgrade/?

What we will update: We will update this post if WordPress changes its rating or adds the CVE to its advisory, if NVD scores CVE-2026-119977, if CISA adds it to KEV, if Wordfence or WordPress confirms a successful compromise or publishes IoCs, or if CISA, CERT-EU or another national CERT issues an alert.

Forward this to your TPRM owner: If your vendors run customer-facing or data-collecting sites on WordPress, ask them this week to confirm in writing that those sites are on a patched release and that /wp-content/upgrade/ is blocked at the web server.

Want an evidence-based view of which vendors in your supply chain run exposed web platforms like this, and how quickly they patch? Talk to Rescana.

Sources

• WordPress (vendor), "WordPress 7.1.4" (28 Oct 2026): https://wordpress.org/news/2026/10/wordpress-7-1-4/
• WordPress HelpHub (vendor), "Version 7.1.4" (28 Oct 2026): https://wordpress.org/documentation/wordpress-version/version-7-1-4/
• WordPress / GitHub (vendor), GHSA-4w3m-c66w-69mg, "A race condition during core updates that could lead to remote code execution" (29 Oct 2026): https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg
• Wordfence (CNA, researcher), "WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release" (29 Oct 2026): https://www.wordfence.com/blog/2026/10/wordpress-7-1-4-security-release-rce/
• CVE Program, CVE-2026-119977: https://www.cve.org/CVERecord?id=CVE-2026-119977
• NIST NVD, CVE-2026-119977: https://nvd.nist.gov/vuln/detail/CVE-2026-119977
• CISA, KEV catalog (live JSON feed): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• CERT-FR, CERTFR-2026-AVI-1420, "Multiples vulnérabilités dans WordPress" (29 Oct 2026): https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-1420/
• Patchstack (researcher), "WordPress 7.1.4 Security Release" (28 Oct 2026): https://patchstack.com/articles/wordpress-7-1-4-security-release/
• The Hacker News, "WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours" (30 Oct 2026): https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html
• SecurityWeek, "Fresh WordPress Vulnerability in Attackers' Crosshairs" (30 Oct 2026): https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/