WordPress CVE-2026-119977 Hits CISA KEV List

CISA adds WordPress Core upgrade race (CVE-2026-119977) to KEV. Patch to 7.1.4 or branch backports; federal deadline Nov 6.

WordPress CVE-2026-119977 Hits CISA KEV List
Image: WordPress logo (Automattic / WordPress Foundation)

CISA just put a WordPress Core race condition on its Known Exploited Vulnerabilities list. If you run WordPress anywhere public — a blog, a client site, a staging box you forgot about — treat this as a patch-now story, not a “wait for the next maintenance window” one.

What happened

On November 3, CISA added CVE-2026-119977 to the KEV catalog after evidence of active exploitation. The bug is a time-of-check/time-of-use race in full-package Core upgrades: WordPress used to unpack the new tree into a predictable, web-served path under wp-content/upgrade/. An unauthenticated attacker who hits that staging installer in the brief window can reach remote code execution. CISA’s own write-up calls out those predictable staging paths; federal civilian agencies have until November 6, 2026 to remediate under BOD 26-04.

WordPress shipped the fix in late October in 7.1.4, with backports down to 4.7.39 (GitHub advisory GHSA-4w3m-c66w-69mg, reported by Umut Bayram). Wordfence scores it CVSS 3.1 8.1. In the first 21 hours after disclosure they counted more than 18,500 requests aimed at staged setup-config.php paths, and The Hacker News says 12,632 exploit attempts were blocked in the last 24 hours as of their report — also crediting Previdian honeypot hits from a UK-geolocated IP on October 30. @TheHackersNews flagged the KEV listing on X.

The race is short (Wordfence says seconds in lab tests), which is why scanners poll continuously. That does not make “we’re probably fine” a strategy once CISA says exploitation is confirmed.

Why it matters

WordPress still powers a huge share of the public web. The vulnerable window only opens during a full Core package update, but that is exactly when many hosts and auto-updaters do their work — and the staging folder is often reachable over HTTP. If you still have sites on anything before the October 28 branch fixes, the next auto-update is itself the dangerous moment. Same class of “update path went sideways” risk we keep seeing around web stacks, whether that is a Collabora path on Nextcloud or a certificate mess after a CA revocation like the one that hit eMudhra keys (7.1.4 also refreshed bundled roots for that revocation, separately from this CVE).

What to do

  • Confirm every site is on 7.1.4 or the fixed release for its branch (7.0.8, 6.9.11 … down to 4.7.39). Dashboard → Updates, or your host’s WordPress manager.
  • Before you update an unpatched site, deny web access to wp-content/upgrade/ at the web server — WordPress only needs filesystem access there. Then update, then verify the Core version.
  • After patching, hunt for unexpected PHP under wp-content/upgrade/, odd admin users, and modified wp-config.php. CISA marks forensic triage required for this KEV entry.
  • If you cannot patch today, keep that upgrade directory blocked and pause full-package Core updates until you can.