CISA Orders Federal Agencies to Patch WordPress Core Flaw by November 6

A newly cataloged vulnerability in WordPress Core has turned a routine maintenance operation, the full-package core update, into a race against attackers. The U.S. Cybersecurity and Infrastructure Security Agency added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, 2026, after concluding that the flaw is being used in the wild. The entry carries a CVSS score of 8.1 and a federal remediation deadline of November 6, 2026.

The defect is a time-of-check time-of-use race condition, usually shortened to TOCTOU. According to CISA, it exists because WordPress Core uses predictable, web-accessible staging paths during full-package upgrades. An unauthenticated attacker who reaches the staging area at the right moment can execute code on the server while the update is still in progress. No account on the target site is required, but the attacker must hit a brief window during a complete Core update.

WordPress addressed the problem in version 7.1.4, which was released on October 28. The affected range covers WordPress Core 4.7.0 through 7.1.3. Public disclosure followed on October 31, and scanning began almost immediately. Wordfence recorded more than 18,500 requests aimed at staged setup-config.php installer paths in the first 21 hours after disclosure, a sign that automated tools were already looking for the opening.

That sequence explains why CISA acted quickly. The agency's catalog is reserved for vulnerabilities with evidence of exploitation, and inclusion carries obligations for Federal Civilian Executive Branch agencies under Binding Operational Directive 26-04. The WordPress entry also requires forensic triage, a signal that simply applying the vendor patch is not the end of the response.

Key Facts

CISA reported on November 3 that CVE-2026-119977 was added to the KEV catalog based on evidence of active exploitation. The agency describes the bug as a WordPress Core TOCTOU race condition that could allow unauthenticated attackers to execute code on the server during the upgrade window. The catalog entry lists CWE-367, the common weakness enumeration identifier for a time-of-check time-of-use condition. CISA's notice gives agencies until November 6 to apply mitigations in line with vendor instructions and BOD 26-04.

The technical scope is narrow but consequential. SecurityAffairs reported on November 4 that the vulnerability affects WordPress versions 4.7 through 7.1.3 and stems from predictable, web-accessible staging directories used during core updates. The fixed release is WordPress 7.1.4. SC Media reported on November 4 that the flaw was reported by Picus Security researcher Umut Bayram and that the CVE record lists October 28 as the disclosure date even though public disclosure occurred on October 31.

The Hacker News reported on November 4 that Wordfence has already blocked thousands of exploit attempts against the upgrade-window flaw. In the most recent 24-hour period cited by the publication, 12,632 attacks attempting to exploit the vulnerability were blocked. Wordfence's telemetry also produced a striking timing detail: the first match for a new firewall rule arrived nine minutes after deployment.

SecurityAffairs reported on November 4 that Wordfence logged more than 18,500 requests targeting staged setup-config.php installer paths during the first 21 hours. Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window. Other sources tested many staging-directory and version-name variations. Previdian honeypot telemetry recorded three exploitation attempts from an IP address geolocated in the United Kingdom, observed on October 30.

CISA has not said who is behind the attacks or how many sites have been compromised. The KEV entry lists known use in ransomware campaigns as unknown, and it requires forensic triage. Those gaps matter because the public evidence so far documents exploitation attempts rather than confirmed breaches. Wordfence's figures describe requests and blocked attacks, not successful intrusions.

Analysis

What this really means is that the danger is not a permanently open door but a short, predictable interval that automated systems can watch continuously. The upgrade window may last only seconds, yet Waseem Ahmed, head of engineering at Secure.com, said, according to SC Media, that even a few seconds of exposure can be sufficient when automated tools continuously monitor vulnerable targets. The Wordfence polling pattern, with sources returning to the same small groups of sites for roughly 14.5 hours, fits that model. Attackers are not guessing blindly; they are waiting for an update event instead of relying on a permanently exposed endpoint.

The bigger picture here is that patch deployment and incident response are separate jobs. Shane Barney, CISO at Keeper Security, said, according to SC Media, that remote code execution gives attackers immediate, unauthenticated control at the server layer, and he warned that remediation cannot stop at applying the patch. Web servers sit next to production databases, internal service accounts and API keys. A compromised upgrade therefore can expose credentials that have nothing to do with WordPress itself. Barney's recommended follow-up includes checking for exploitation and rotating database passwords, API keys and service credentials.

Sina Chehreghani, head of threat intel and threat research at Securonix, gave a plain account of the mechanism, according to SC Media: during an update WordPress extracts new files into a predictable directory under the web-accessible upgrade folder, and an unauthenticated attacker who reaches that staging area before files are moved or removed may invoke PHP code and execute commands with the web server's privileges. That detail explains why the KEV listing includes forensic triage. A patched site can still be a compromised site if an attacker won the race before the update completed.

The response guidance reflects that risk. Security teams should block external web requests to PHP files under /wp-content/upgrade before upgrading, monitor for repeated requests to setup-config.php that return HTTP 200, hunt for rogue administrator accounts and modified wp-config.php files, and retest externally after patching. Those steps are not a substitute for installing 7.1.4. They are the difference between closing the known hole and determining whether someone already used it.

Why It Matters

The flaw sits in WordPress Core rather than in a plugin or theme, so the affected code path is the core update process itself. That places the exposure in the core update mechanism rather than in an optional add-on. The vulnerability does not require an account on the site, and the exploitation condition is tied to a routine administrative action. For defenders, the lesson is that an update can be both the fix and the moment of exposure.

The federal deadline gives the issue a clear test. CISA's directive applies to Federal Civilian Executive Branch agencies, but the agency encourages all organizations to adopt risk-based vulnerability management and to prioritize KEV entries. A November 6 due date leaves little room for a slow inventory cycle. Agencies and private operators alike need to know which assets run affected versions, whether those assets completed a full-package core update during the exposure period, and whether the web server can reach sensitive credentials.

The public record also shows how quickly opportunistic scanning follows disclosure. CISA added the flaw to the KEV catalog on November 3, three days after the October 31 public disclosure and six days after the October 28 patch. Within the first 21 hours, Wordfence saw more than 18,500 requests against staged installer paths. That volume does not prove widespread compromise, but it does show that the window between patch release and mass probing is short enough that manual review alone is a weak control.

Next Up

Federal agencies have until November 6 to remediate CVE-2026-119977 and complete the forensic triage required by the KEV entry. Private organizations are not bound by the same deadline, but CISA's guidance and the researchers' recommendations point to the same sequence: move to WordPress 7.1.4, restrict access to the upgrade staging area, inspect logs for setup-config.php requests that returned HTTP 200, and review administrator accounts and wp-config.php for unauthorized changes.

CISA has not identified the attackers or disclosed a count of compromised sites, leaving the public picture focused on attempted exploitation. Wordfence's blocked-attack figures and Previdian's three honeypot observations are the main early signals. The next useful evidence will come from organizations that check their own logs rather than from the absence of a reported breach. Until then, the safe assumption is that any site that ran an affected version through a full-package core update during the exposure period should verify both the patch and the integrity of its server credentials.