WordPress CVE-2026-119977: Upgrade Race Hits CISA KEV

CISA added WordPress CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, with a November 6 deadline for federal agencies. The flaw is a race condition in core updates that can let an unauthenticated attacker run code while an update unpacks. It affects versions 4.7 through 7.1.3. Confirm every site is on 7.1.4 or its branch fix, then deny web access to wp-content/upgrade/ at the web server.

What happened

WordPress released 7.1.4 on October 28, 2026. Patchstack counts 22 vulnerabilities across 17 advisories in the release. Nearly all of them need an account first. The exception is the upgrade flaw, reported by Umut Bayram, which needs no account and no user interaction.

Attack traffic started quickly. Rescana's timeline says Wordfence deployed a firewall rule for paying customers on October 28 and saw the first matching request nine minutes later. Wordfence reported more than 18,500 requests against staged installer paths in the first 21 hours. The Hacker News then reported that Wordfence blocked 62,969 attacks in 24 hours. Rescana could not find that second figure in Wordfence's own post, so treat it as press reporting of a vendor count.

Wordfence, acting as the CVE Numbering Authority, published the CVE record on October 31. CISA's catalog entry followed on November 3. The entry marks forensic triage as required and lists known ransomware use as unknown.

Who is affected by CVE-2026-119977

The CVE record covers WordPress 4.7.0 through 7.1.3. The fixed release depends on the branch:

7.1: fixed in 7.1.4
7.0: fixed in 7.0.8
6.9: fixed in 6.9.11
6.8: fixed in 6.8.12
6.7: fixed in 6.7.11
6.6: fixed in 6.6.11
6.5: fixed in 6.5.14
6.4: fixed in 6.4.14
6.0 through 6.3: fixed in 6.0.18, 6.1.16, 6.2.15 and 6.3.14
5.0 through 5.9: fixed in 5.0.31 up to 5.9.20, per the WordPress advisory
4.7 through 4.9: fixed in 4.7.39, 4.8.34 and 4.9.35

Versions 4.6 and older get no fix. WordPress.org statistics cited by webhosting.today on October 29 put 0.95% of sites in that group, with 34.6% on branches 4.7 through 7.0 and 64.4% on 7.1.

A site must meet four conditions, according to Wordfence's analysis as reported by The Hacker News:

A full-package core update is running.
The staging tree under wp-content/upgrade is reachable over the web and can run PHP.
The staging path is predictable or has been discovered.
The attacker finishes before WordPress removes the temporary files.

Technical analysis

During a full-package update, affected versions unpack the new release into a predictable folder under wp-content/upgrade/. The WordPress advisory describes this as extraction to "a predictable directory inside the web-served upgrade folder." Patchstack adds that the cleanup step deleted the index.php file that stops the folder being listed.

For those few seconds, a complete WordPress copy sits at a guessable path. That copy includes the installer, wp-admin/setup-config.php, which can run without the live site's configuration. The result is a classic time-of-check to time-of-use race condition, recorded in the CVE as CWE-367.

Wordfence says the window normally lasted only seconds in lab testing. That explains the traffic pattern it reported: two of the largest sources polled small groups of sites for roughly 14.5 hours, and others tried many directory and version-name variations. Wordfence also said that not every request used the exact vulnerable path.

Version 7.1.4 appends 16 random characters to the folder name, recreates index.php and stops deleting it. Patchstack also found a change the release post does not mention: wp-config.php joined the list of files a core update never copies out of the working directory.

PHP firewalls have a blind spot here. Patchstack explains that the extracted copy loads WordPress from its own files, so a firewall running inside the live site never sees the request. Web server rules still apply.

Why the ratings disagree

The same bug carries three signals. The WordPress advisory rates it Low. The CVE record scores it CVSS 8.1 High (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). CISA lists it as exploited. Patchstack scored the attack complexity as high and said it "would not call it practical to exploit."

None of these contradict each other. They answer different questions, which we cover in why vendor severity and CVSS scores disagree. CISA's published criteria count attempted exploitation as active exploitation, while plain scanning does not qualify. A KEV listing therefore does not prove that a site was taken over, and the sources we read report attempts, not confirmed compromises. CISA has not published the evidence behind this entry.

What to do now

Add the block first. Follow our guide on how to block web access to wp-content/upgrade before you start the update. Rescana points out that the update to 7.1.4 is still unpacked by the old code, so that final update can open the window once more.
Update every site to 7.1.4 or the fix for its branch. WordPress says sites that support automatic background updates will update on their own. Check the version anyway, using Dashboard, then Updates, or your fleet tooling.
Find the long tail: sites with automatic updates turned off, installs on 4.6 or older, and sites run by agencies or hosts outside your patch process.
Review logs from any time a core update ran on an unpatched site. Wordfence advises looking for unexpected requests to PHP files beneath wp-content/upgrade, unfamiliar administrator accounts, unexpected plugins and PHP files you did not place there.
If you find any of those, treat the site as compromised. Our guide on cleaning a backdoored WordPress site covers the follow-up work.

Federal civilian agencies must meet the KEV deadline and follow the forensic triage requirements in BOD 26-04. Everyone else should treat the date as a useful outer limit.

Hosted customers should check with their provider. Pantheon, for example, labeled 7.1.4 "Action required" and deployed platform-wide mitigations, while still telling customers to update. If you rely on the Wordfence plugin, Rescana reports that free users receive the firewall rule on November 27, so do not count on it before then.

What to watch next

Watch for a CISA or Wordfence statement confirming a successful compromise, published indicators of compromise, or a working public exploit. Rescana found no network indicators from WordPress or Wordfence as of October 31. The WordPress advisory also still showed "No known CVE" when we read it, so a scanner keyed to that advisory may not match the CVE ID.

This is the second WordPress core flaw to reach attackers within hours of a patch in about five weeks, after CVE-2026-87902 in September. The patch alone does not answer whether each site actually updated, so check that directly.