Cyber One Solutions logo.
Get Support

Security Advisory

CISA Confirms Active Exploitation of a WordPress Core Flaw That Attacks During the Update Process Itself

November 4, 2026 · Cyber One Solutions Security Team

CISA added CVE-2026-119977, a WordPress core race-condition flaw, to its Known Exploited Vulnerabilities catalog on November 3, 2026, with a November 6 remediation date. Unlike most patch-now advisories, this one is exploited during the brief window a site is already updating, and security firms report tens of thousands of attempts to catch that window. Here is what it is, who it reaches, and what to do before and during your next WordPress update.

On November 3, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalog, listed under vendor WordPress and product WordPress Core as a Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability. CISA's short description for the entry says the flaw "could allow unauthenticated attackers to execute code on the server during the upgrade window," and that "this is due to predictable, web-accessible staging paths used during full-package core upgrades," per CISA's Known Exploited Vulnerabilities catalog entry for CVE-2026-119977. CISA's required action directs stakeholders to apply vendor mitigations and follow Binding Operational Directive 26-04 guidance, including its forensic triage requirements, with a November 6, 2026 remediation due date that binds U.S. federal civilian agencies rather than private businesses. CISA only adds a flaw to that catalog when it has reliable evidence attackers are already using it, and the official CVE record's CISA-contributed assessment separately rates the exploitation status "active," so this listing confirms real-world attack activity, not a theoretical risk, per the official CVE-2026-119977 record published through MITRE's CVE Services.

An Unusual Way to Get Attacked: During the Update Itself

Most of the advisories we cover tell you to patch a specific flaw as soon as possible. This one is different, because the vulnerable moment is the update process itself. The CVE record, assigned by the security firm Wordfence as the official CVE Numbering Authority for this flaw, titles it "WordPress Core 4.7.0 - 7.1.3 - Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution" and rates it 8.1, High, under CVSS 3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, classified under CWE-367, Time-of-check Time-of-use (TOCTOU) Race Condition. In plain terms: no account or password is needed (PR:N) and no action from a visitor is required (UI:N), but the attack takes high effort to pull off (AC:H), because the attacker has to win a race against the clock. WordPress credits security researcher Umut Bayram with discovering and reporting the flaw, per WordPress's own 7.1.4 security release announcement, which fixed it along with eleven other, lower-severity issues.

The mechanism, as described in security researchers' analysis of the fix and the CVE record's own references to the affected WordPress source files, is this: when a WordPress site runs a full-package core update, rather than a smaller incremental one, WordPress extracts the new version's files, including a copy of WordPress's own installer, into a temporary working directory under wp-content/upgrade/. On many servers that directory is reachable directly over the web. If an attacker requests the staged installer at the right moment during that brief extraction window, before WordPress deletes the temporary files, the attacker can interact with it and progress to running code on the server. Researchers who examined WordPress's fix report that 7.1.4 closes the gap by giving the staging directory an unpredictable, randomly generated name, keeping a protective index.php file in the upgrade folder so its contents cannot be browsed, and no longer carrying wp-config.php out of the temporary directory. The official CVE record's affected-version data shows every WordPress branch back to 4.7 was vulnerable up through its pre-fix release (4.7.0 through 7.1.3 overall), and WordPress's own announcement says fixes were backported "to all branches eligible to receive security fixes (currently through 4.7)"; 4.6 and earlier no longer receive security updates at all and have no fix available.

Attackers Are Already Racing the Clock

Security researchers report large volumes of automated attempts to catch this exact window. A report from The Hacker News, citing the security firm Wordfence, says Wordfence blocked 62,969 attacks targeting the flaw over a 24-hour period, with two of its largest traffic sources each repeatedly polling small groups of sites for roughly 14.5 hours, a pattern Wordfence considers consistent with attackers trying to catch a site in the middle of updating. Wordfence has not publicly reported a confirmed successful compromise as of this writing, and WordPress's own advisory rates the issue's severity as Low, in contrast to Wordfence's CNA-assigned High rating, a split that likely reflects how narrow the attack window is in practice rather than a disagreement over what the flaw can do once exploited. That gap between "widespread scanning" and "confirmed breach" will not necessarily hold, and CISA's own active-exploitation listing means this has already moved past the scanning-only stage CISA treats as significant enough to warrant federal remediation deadlines.

Who Is Affected, and What to Do Now

This reaches any business running a self-hosted WordPress site, the platform behind a large share of small-business websites, that has not yet updated to WordPress 7.1.4 or the corresponding fixed release for its branch. Sites where a host or developer disabled core auto-updates are the ones most likely to still be exposed; WordPress.com's own fully managed hosting handles core updates automatically and is not the concern here.

Why This Belongs on Your Radar

A flaw that is exploited by racing the update process itself is an unusual category, and it means the advice most businesses already follow, "keep software updated," is not quite enough on its own this time; the moment of updating is the moment of risk until the update finishes. For businesses subject to the FTC Safeguards Rule or the HIPAA Security Rule, the same obligations we have flagged for earlier advisories apply here. The FTC Safeguards Rule requires nonbanking financial institutions to maintain a documented information security program that includes vulnerability monitoring under 16 CFR 314.4(d)(2), though institutions maintaining customer information on fewer than 5,000 consumers are exempt from that paragraph. HHS Office for Civil Rights guidance treats identifying and remediating known, actively exploited vulnerabilities as part of the ongoing risk analysis and risk management obligations at 45 CFR 164.308(a)(1)(ii)(A) and (B); a WordPress site that creates, receives, maintains, or transmits ePHI, directly or through a patient-facing contact form or portal, falls within that scope.

If Cyber One Solutions designs, hosts, or maintains your website through our website design, hosting, and maintenance service, platform patching and the kind of precaution described above are part of that ongoing engagement rather than something you need to track yourself. If you manage your own WordPress site, or work with a developer or host you are not fully confident is tracking advisories like this one, our managed cybersecurity service can monitor vendor advisories against what you actually run, and our IT and security assessments can tell you what is on your server today and whether this fix is already in place.

Sources