PolicyCortex
Request Access
Summary
  • CISA added the WordPress upgrade flaw to its exploited list on November 3, 2026.
  • The flaw affects WordPress 4.7 through 7.1.3.
  • The fix is 7.1.4 or the patched release for your branch.
  • Patching alone does not answer whether entry happened before the patch.

What changed on November 3

The Cybersecurity and Infrastructure Security Agency (CISA) added one flaw to its list. The list is the Known Exploited Vulnerabilities (KEV) catalog. CISA lists a flaw there only when it has evidence of active exploitation. The new entry is CVE-2026-119977. Common Vulnerabilities and Exposures (CVE) is the record system for public flaws. Federal civilian agencies must act by November 6, 2026. CISA also asked for forensic triage. That means teams must check for entry, not just patch.

How the flaw works

WordPress Core has a Time-of-check Time-of-use (TOCTOU) race condition. Common Weakness Enumeration (CWE) 367 names this weakness type. During a full package core upgrade, files unpack into a staging path under wp-content/upgrade. That path is predictable on affected versions. It is also web accessible on many servers. An attacker with no login can request the staged installer at the right moment. That request can lead to code execution on the server. The window is short, often seconds. Repeated polling raises the chance of hitting it.

Which versions are affected

The flaw affects WordPress 4.7 through 7.1.3. WordPress released 7.1.4 on October 28, 2026. That release is a security release. It fixes 22 vulnerabilities in total. The upgrade window flaw is the most serious of them. WordPress backported fixes to branches back to 4.7. Fixed releases include 7.0.8, 6.9.11, 6.8.12, and 6.7.11, down to 4.7.39. WordPress 4.6 and older get no fix. Those sites must move to a supported release.

What attempt data shows, and what it does not show

Wordfence is the CVE Numbering Authority (CNA) that assigned this record. Wordfence published the record on October 31, 2026. Wordfence scores the flaw 8.1 High under Common Vulnerability Scoring System (CVSS) version 3.1. Wordfence reported more than 18,500 requests in the first 21 hours after its firewall rule went live. Those requests targeted staged installer paths. The Hacker News later reported 12,632 blocked attempts in a 24 hour window. These counts describe attempts. They are not a count of successful break-ins. Do not read them as proof that any one site fell. The KEV listing is the exploitation signal. Your own logs are the site level proof.

What to do now

First, confirm your exact WordPress version. Do not assume an automatic update finished. Second, move to 7.1.4 or the patched release for your branch. Third, block web access to wp-content/upgrade until the patch is in place. Fourth, search logs for requests to staged installer paths. Fifth, look for new admin accounts, unknown plugins, and files you did not place. Sixth, rotate credentials if you find any sign of entry. Record each step with a date.

The governance lesson

An updater flaw breaks a basic trust. The update path itself must be safe. A patch queue that treats updates as routine misses that point. When CISA lists a flaw, move it to the front of the queue. Record the version before the patch and after it. Record the patch date and the scan result. Record the hunt result for signs of entry. A patch note with no hunt result leaves the breach question open. That gap is what an assessor will find first.

Sources

Next step

Confirm your WordPress version today, patch to the fixed release, then record the hunt result.

Questions on this record
What is the upgrade window flaw?
During a full package core upgrade, files unpack into a predictable staging path. An attacker with no login can reach that path and run code during the upgrade window.
Which versions are fixed?
Version 7.1.4 is fixed. Branch releases back to 4.7.39 are also fixed. Version 4.6 and older get no fix, so those sites must move to a supported release.
What is the federal deadline?
Federal civilian agencies must act by November 6, 2026. That date comes from the CISA listing. Other teams should treat it as their deadline too.
Does the listing prove a break-in on my site?
No. The listing shows CISA has evidence of active exploitation in general. It does not prove entry on any one site. Check your own logs and files.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

proof.state
Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change
Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency
Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture
Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.

Further reading in this register

  1. Barracuda Email Gateway Chain Needs a Fast Patch, and a Close ReadBarracuda patched a 9.3 gateway flaw and an 8.6 command injection flaw on November 2, 2026. Chained on Email Security Gateway, they could yield root access. Read the advisory closely before you judge exposure.5 min
  2. cPGuard Update Channel Compromise: Malicious Script in Updates 5.88.12 to 5.88.19A compromised update channel sent a malicious script to cPGuard servers. Update to 5.88.25 or later, check the indicators, and rotate exposed secrets.5 min
  3. Langflow Flaws Let Attackers In Without an AccountTwo flaws in Langflow score 9.8. An attacker needs no account to bypass checks or run code through agent tools.3 min

Verify the record this entry describes.

Request AccessBook a call
Published
Last updated
Unchanged since publication
Author
Leonard Esere