CVE-2026-119977: WordPress Core Flaw Added to CISA KEV

CISA added CVE-2026-119977, a race condition in WordPress Core's upgrade process, to its Known Exploited Vulnerabilities (KEV) catalog on November 3, 2026, with a federal due date of November 6. The flaw lets an unauthenticated attacker run code on the server during a full-package core update, and it affects WordPress 4.7 through 7.1.3. WordPress shipped the fix in 7.1.4 on October 28, so the KEV entry came six days after the patch. What sets this bug apart is when the exposure exists: only while a core update is running, which on many sites happens automatically and unattended.

What happened

WordPress 7.1.4 came out on October 28, 2026 as a security release. The first of its listed fixes is a weakness in the upgrade process that can lead to remote code execution during the upgrade window, credited to Umut Bayram. The announcement gives no CVE number. It says sites that support automatic background updates will begin the update on their own, and that the fixes are backported to every branch eligible for security fixes, currently back to 4.7, with the backports shipping as they become ready.

The CVE, CVE-2026-119977, was published on October 31, and the CVSS score of 8.1 comes from Wordfence. Attack traffic was visible almost immediately. THN reported on October 30 that Wordfence had blocked 62,969 attacks in a 24-hour period, with two large sources polling small groups of sites for about 14.5 hours. In its later report on the KEV listing, THN says Wordfence recorded more than 18,500 requests aimed at staged setup-config.php installer paths in the first 21 hours after public disclosure, and 12,632 attacks blocked in the last 24 hours as of writing on November 4. Previdian logged three exploitation attempts against its honeypot sensors on October 30, from an address geolocated in the UK.

The figures count attempts, not compromises. Other coverage notes that no working public exploit had been confirmed as of October 30, and Rescana says no successful compromise had been reported. CISA's entry nonetheless cites evidence of active exploitation.

The flaw and who is affected

CVE-2026-119977 is a time-of-check time-of-use race condition, classified as CWE-367. During a full-package core update, WordPress unpacks the new release into a staging directory under wp-content/upgrade. Wordfence describes the staging paths as predictable and web-accessible, and the staged copy includes the installer, such as setup-config.php. A request that reaches that PHP file while the update is running executes it without loading WordPress and without any login.

THN lists four conditions for exploitation: a full-package update that includes the installer files, public web and PHP access to the staging path, a path that is predictable or can be discovered, and enough time before the files are cleaned up. In lab tests the window has been observed to last only seconds. That fits an 8.1 score for a bug that needs no account, because the cost to the attacker is timing, not access.

WordPress 4.7 through 7.1.3 are affected, and 7.1.4 is fixed. For older lines, Rescana's summary of the WordPress GitHub advisory lists these fixed releases; confirm them against the advisory before you rely on them:

Branch	Fixed in
7.1	7.1.4
7.0	7.0.8
6.9	6.9.11
6.8	6.8.12
6.7	6.7.11
6.6	6.6.11
6.5	6.5.14
6.4	6.4.14

Older 5.x and 4.x lines are covered in the same summary. WordPress says backports reach branches back to 4.7, so an install older than that has no fix and needs to move to a supported branch.

Attackers do not need to time your update, they wait for it

A window of a few seconds sounds like a hard target. The traffic shows how attackers solved it: they do not try to catch the moment, they poll for it. THN describes two large sources checking small groups of sites for about 14.5 hours, and Wordfence's counts of 18,500 requests in 21 hours and 62,969 blocked attempts in one day are what continuous polling looks like. Nobody has to know when you will patch. A poller only has to be asking when it happens.

That is where the usual signals understate the risk. VulnTracker's SSVC reads Not automatable, and EPSS is 0.6%, yet the observed traffic is automated, because the part that cannot be automated is only the timing and waiting removes it. WordPress's own wording adds a second angle: sites with background updates enabled run the update by themselves, at any hour, with nobody watching the site while it happens.

The fix is the same update that opens the window, which is the awkward part. Until a site has finished updating, the cheapest protection sits at the web server, in keeping the staging path from being reachable at all.

Reading it on VulnTracker

The record for CVE-2026-119977 was published on October 31, 2026 and updated on November 4. It shows CVSS 3.1 8.1 High from Wordfence, EPSS at 0.6% (higher than 49% of CVEs), CWE-367 and an NVD status of Undergoing analysis. SSVC reads Active, Not automatable, Total impact. The KEV panel shows the entry added on November 3, 2026 with a due date of November 6, 2026, and the record notes the WordPress 7.1.4 announcement and the Wordfence advisory among its references.

The affected view lists one product from one vendor, WordPress Core, with each minor series from 4.7.0 up to 7.1.0, so treat any release below the fixed version of its line as in scope. The remediation guide is empty and no vendor advisories are attached, so take fixed versions from WordPress's own release notes.

What to do

Federal agencies are due on November 6, 2026. Everyone else can use the same date as a target.

Update WordPress Core. Move to 7.1.4 or the fixed release for your branch, from Dashboard, Updates, or by downloading the package from WordPress.org. If you rely on automatic background updates, confirm they are not switched off in wp-config.php or by your host, and check the version number afterward instead of assuming it ran.
Keep the staging path closed to the web. Deny web access to wp-content/upgrade/ at the web server and confirm the directory is not listable. This does not replace the update, and it also helps during the update itself.
Review logs around core updates. Look for requests to PHP files under wp-content/upgrade/, especially repeated requests to setup-config.php, since polling is the pattern reported so far. No indicators such as IP addresses or file hashes have been published.
Check the sites for signs of a takeover. Look for administrator accounts you do not recognize, plugins you did not install and PHP files in unexpected places, and rotate admin and database credentials on any site where something looks wrong.
Move unsupported installs. WordPress backports reach branches back to 4.7, so anything older needs a supported branch.
If you run Wordfence, enable its Extended Protection so the firewall rule is active on your sites.

Takeaway

Most WordPress flaws wait for a plugin, a login or a visitor. This one waits for your own update. The fix has been out since October 28, the attacks are polling for the moment a site patches, and an unattended auto-update is exactly the kind of event they are waiting for. Check that your sites are on a fixed release, and keep the staging path away from the web.

To see which WordPress branches fall under CVE-2026-119977 and how the record changes as NVD finishes its analysis, track WordPress on VulnTracker.