WordPress Core RCE on CISA's KEV List: When the Update Itself Is the Exposure

On November 3, 2026, CISA added a WordPress core vulnerability, CVE-2026-119977, to its Known Exploited Vulnerabilities (KEV) catalog. The flaw lets an unauthenticated remote attacker run code on the server, but only during a narrow window while WordPress unpacks a full-package core update. The fix shipped on October 28 in WordPress 7.1.4, and federal agencies have until November 6 to apply it.

The bug is hard to exploit, which is why it was rated low by WordPress itself. It still matters to security leaders, because it sits on a platform that most organizations run somewhere, often outside the patch process, and because attackers started probing it within hours of the release.

What Happened

According to Wordfence, which also assigned the CVE, WordPress unpacks new core files into a predictable directory under wp-content/upgrade/ during a full-package update, and that copy includes the installer files. If that directory is reachable from the web and PHP will execute files there, an attacker who hits the right moment can reach staged files before WordPress cleans them up. Wordfence describes the window as lasting seconds in its lab tests, and says repeated automated polling can improve an attacker's odds. No account is needed.

Wordfence lists four conditions that must all hold: a full-package core update is in progress, the staging tree is publicly reachable with PHP execution, the path is predictable or discoverable, and the attacker acts before cleanup. That is why the attack complexity is rated high. It is also why the bug is easy to underestimate. Every full-package update, including automatic ones, reopens the window on an unpatched site.

Timeline

October 28: WordPress 7.1.4 and backports are released. Wordfence deploys a firewall rule for paid customers.
October 29: WordPress publishes its GitHub security advisory. Wordfence publishes its analysis and reports probing.
October 30: The Hacker News reports Wordfence's blocked-attack count.
October 31: The CVE record is published.
November 3: CISA adds the flaw to KEV.
November 6: Federal due date.
November 27: Wordfence says its firewall rule reaches free-tier users.

Affected and Fixed Versions

Reporting says WordPress core from 4.7 through 7.1.3 is affected, with fixes in 7.1.4 and backports for older branches, going back to 4.7.39. One analysis lists, for example, 7.0.8, 6.9.11 and 6.8.12 as fixed releases for those branches, and says 4.6 and earlier get no fix and need to move to a supported release. Confirm your exact branch against the official WordPress advisory before you rely on this list.

Confirmed vs Still Unclear

Reasonably well supported across sources:

The flaw is a time-of-check to time-of-use race (CWE-367) in core upgrade handling, fixed in 7.1.4.
Wordfence scored it CVSS 8.1 (High). WordPress's own advisory rates it low, and Patchstack scored attack complexity as high.
CISA added it to KEV on November 3 based on evidence of active exploitation.

Unclear or disputed:

Attack volume. The numbers differ because they measure different things. Wordfence counted more than 18,500 requests to staging paths in the first 21 hours after its rule went live. The Hacker News reported 62,969 blocked attacks in 24 hours, citing Wordfence, in a figure that another outlet could not find in Wordfence's own post. Later reports cite about 12,600 to 13,100 blocked attempts in a 24-hour period. Treat all of these as vendor telemetry from a single firewall vendor's customer base, not a count of victims.
Compromise. Wordfence reports probing and no confirmed successful compromise, and CISA has not described specific incidents. A KEV listing means exploitation evidence exists, not that you were breached.
Attribution. No source names a threat actor. Previdian reportedly recorded three attempts against a honeypot on October 30, which is a small sample from one source.
Who found it. BleepingComputer credits Umut Bayram of Picus Security. I did not see this confirmed elsewhere.
Indicators. None of the sources I read publish network indicators such as IP addresses or file hashes.

Why This Is a GRC Problem

1. Inventory of what runs WordPress

Marketing sites, event microsites, acquired brands, agency-built landing pages and managed hosting accounts all run core. If your inventory tracks servers but not applications and their versions, you cannot say which sites were exposed during the last update.

2. The risk lives in the update itself

Most patch conversations assume the system is safe once updated. Here the exposure appears while updating, and it is tied to how the web server is configured. That makes this a change management and configuration baseline question, not only a patching one.

3. Third parties own part of the fix

Managed WordPress hosts and agencies control core updates for many organizations. Ask them in writing which versions they run, whether staging directories are blocked at the web server, and when they patched.

4. A plugin firewall is not the control here

Patchstack notes that a firewall loaded by WordPress cannot stop this attack, because the request goes to a staged PHP file directly. Wordfence recommends its Extended Protection mode, which runs before direct PHP requests. If you rely on any WAF, record it as a temporary compensating control with an expiry date.

5. Evidence for auditors

Assessors will ask for proof that you triaged a KEV-listed vulnerability on a defined timeline, including the sites you decided were out of scope and why. Keep that record as you go.

Control Mapping

Framework	Relevant control area
NIST CSF 2.0	ID.AM (asset inventory), ID.RA (risk assessment), PR.PS (platform security), DE.CM (continuous monitoring)
ISO/IEC 27001:2022	A.8.8 Management of technical vulnerabilities, A.8.9 Configuration management, A.8.32 Change management, A.5.19 to A.5.22 Supplier relationships
SOC 2	CC7.1 (vulnerability detection), CC8.1 (change management), CC9.2 (vendor risk)
HIPAA Security Rule	164.308(a)(1)(ii)(A) risk analysis and (B) risk management

Action Plan

Next 24 hours

List every WordPress install you own or pay someone to run, including agency and hosting-provider sites. Record the version.
Update to the fixed release for your branch and verify the running version afterward.
At the web server or virtual host, deny public access to wp-content/upgrade/ and disable directory listing. Wordfence and Patchstack both describe this as a mitigation, and it works whether or not the site is patched yet.
Preserve web server access logs for the period since October 28.

Next 7 days

For sites that ran a full core update while unpatched, search logs for requests to PHP files under wp-content/upgrade/.
Check for unfamiliar administrator accounts, unexpected plugins and PHP files nobody deliberately placed. Wordfence suggests these checks.
Confirm that automatic background updates are enabled where policy allows, and list the sites where they are off.
Collect written patch status from hosting providers and agencies.

Next 90 days

Add application name, version and owner to the asset inventory for all web properties.
Make the web server rule blocking upgrade staging paths part of your standard hosting baseline.
Retire or formally risk-accept any site on a WordPress branch that no longer receives fixes.
Test whether your emergency change process can push a KEV-listed fix in the time your policy states.

Final Thoughts

This is not the loudest vulnerability of the year, and the technical bar for attackers is higher than usual. That is the lesson. A bug rated low by its own vendor still landed on the KEV list within a week, because exploitation tooling does not care about severity labels. Organizations that know where WordPress runs and can change a web server rule in an afternoon will close this quickly. Everyone else will spend the week finding their sites first.

This story is still developing, so confirm versions, scores and guidance against WordPress, CISA and your vendors before you act on any single article, including this one.