WordPress Core CVE-2026-119977: Update Before the Upgrade Window Becomes an Open Door — Federal Deadline November 6
WordPress pushed security patches to every maintained branch on October 28. The flaw they close — a race condition in the core upgrade mechanism — lets an unauthenticated attacker slip malicious code onto a site during the seconds it takes to unpack a core update. CISA added it to the Known Exploited Vulnerabilities catalog on November 3. The federal deadline is November 6. If you run WordPress and have not yet updated, that deadline is not academic.
What: CVE-2026-119977 — a time-of-check to time-of-use (TOCTOU) race condition, CWE-367, in the WordPress core full-package upgrade mechanism. Wordfence (the CVE Numbering Authority) scores it CVSS v3.1 8.1 High (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Affects WordPress 4.7.0 through 7.1.3 and all maintained older branches.
Status: Actively exploited in the wild. CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, 2026. Wordfence reported 20,141 blocked exploit attempts in the 24 hours before its November 3 review. CISA marks known ransomware use as Unknown.
Deadline: November 6, 2026 for all Federal Civilian Executive Branch agencies under CISA’s Binding Operational Directive 22-01.
Fix: Update to WordPress 7.1.4 (released October 28, 2026), or to the branch-specific fixed release for your installed version. No workaround is available; the fixed release is the required endpoint.
Key takeaways
- WordPress Core CVE-2026-119977 is on CISA KEV with a November 6 federal deadline — just two days from publication of this briefing.
- Fixed builds are already available: WordPress 7.1.4 is the current-line fix; every maintained branch from 4.7 onward received its own patch on October 28, 2026.
- The exploit targets a predictable staging path during core upgrades, not the live site itself. An attacker who reaches the upgrade window and wins the race can execute PHP code on the server without any credentials.
- Wordfence blocked 20,141 CVE-2026-119977 exploit attempts in 24 hours; its firewall rule matched its first request nine minutes after going live. Two large scanners ran continuously for over 14 hours, according to Wordfence.
- No IP-based or hash-based IoCs have been published. Detection depends on request patterns — specifically, unauthenticated HTTP requests targeting staged
setup-config.phppaths underwp-content/upgrade/. - WordPress and Wordfence rate CVE-2026-119977 differently. WordPress calls it Low; Wordfence (the CNA) rates it CVSS 8.1. CISA’s KEV listing confirms active exploitation and renders that disagreement secondary.
Executive Summary
The WordPress update mechanism became the attack surface.
When WordPress performs a full-package core upgrade, it downloads the new release, unpacks it into a staging directory under wp-content/upgrade/, then copies the files into place. Before the October 28 fix, that staging directory had a predictable name and was web-accessible. The staged package contains a copy of the WordPress installer — setup-config.php — the same file used to configure a fresh installation. An attacker who reached that path during the upgrade window could execute it directly.
The window is short in lab tests: seconds. The attack compensates by polling repeatedly, flooding the site with requests and relying on volume to catch the right moment. Wordfence observed that pattern: scanners sending requests continuously for more than 14 hours, waiting for an upgrade to begin. When one does, they are already waiting at the door.
The October 28 patches close the attack in three ways: the staging directory name is now randomized, a blank index.php blocks directory listing, and the upgrader refuses to copy a staged wp-config.php over the live one. For anyone still running 7.1.3 or any earlier affected version, none of those protections are present.
DataWater previously covered an earlier WordPress Core unauthenticated RCE in wp2shell CVE-2026-63030. CVE-2026-119977 is a distinct vulnerability — a different mechanism, a different code path, and a wider affected range going back to version 4.7.0.
Why This Matters to CISOs and Security Leaders
WordPress powers an estimated 40 percent or more of the web. The affected version range stretches from 4.7.0 through 7.1.3 — roughly nine years of releases. Any site in that range that has run a full-package core update since the flaw became exploitable is a candidate for targeting.
The upgrade you run to protect the site is briefly the attack surface. While a manual or automatic update is in progress, the site is momentarily exposed. Automated updates, which many hosts use to keep WordPress current, do not eliminate the window — they just move it to off-hours, when SOC staffing may be thinner and the update may go unmonitored.
The KEV listing sets the floor for enterprise policy. Per CISA’s Binding Operational Directive 22-01, federal agencies must patch by November 6. Many enterprise security programs treat the KEV as a minimum-baseline for all environments, not just federal. If your patch SLA for a KEV-listed critical vulnerability is longer than three days, now is the time to test whether that SLA is real.
Ask your team: “Do we know which of our WordPress instances ran a full-package core update between October 28 and today, and do we have logs that could tell us whether anyone was polling the upgrade path at that time?” The answer to the second question is usually no — which is itself a gap worth closing before the next WordPress zero-day.
The Timeline
| Date (2026) | What happened |
|---|---|
| October 28 | WordPress releases 7.1.4 and branch-specific fixes for all maintained versions back to 4.7.39, addressing CVE-2026-119977. GitHub Advisory GHSA-4w3m-c66w-69mg published. |
| October 28 | Wordfence firewall rule deployed; first exploit match logged nine minutes after the rule went live, per Wordfence. |
| October 28–31 | Two large scanners observed polling continuously for over 14 hours each, targeting staged installer paths. More than 18,500 requests logged in the first 21 hours after disclosure, per Wordfence. |
| October 30 | Previdian honeypot records three CVE-2026-119977 exploitation attempts from an IP geolocated in the United Kingdom (single-source). |
| November 3 | CISA adds CVE-2026-119977 to the Known Exploited Vulnerabilities catalog. Federal deadline set for November 6, 2026. |
| November 3–4 | Wordfence reports 20,141 blocked CVE-2026-119977 attempts in the 24 hours leading up to its November 3 review. The Hacker News and other outlets cover the CISA KEV addition. |
| November 6 | CISA remediation deadline for all Federal Civilian Executive Branch agencies under BOD 22-01. |
Attackers don’t need to break into WordPress. They just need to be waiting at the right path when the updater unpacks.
Vulnerability & Exploit Analysis
What CVE-2026-119977 is
CVE-2026-119977 is a time-of-check to time-of-use (TOCTOU) race condition — classified as CWE-367 — in the WordPress core full-package upgrade mechanism. During a core update, WordPress downloads and unpacks the new release into a staging directory under wp-content/upgrade/. Prior to the October 28 patch, that directory had a predictable name and was web-accessible. The staged package contains a copy of the WordPress installer (setup-config.php), the same file that sets up a fresh WordPress installation. A network-reachable, unauthenticated attacker who requests that file while the upgrade is in progress may be able to execute it, potentially resulting in arbitrary code execution on the server.
The October 28 fix addresses the exposure in three ways: the staging folder name is randomized, a blank index.php is added to prevent directory listing, and the upgrader is modified to refuse copying a staged wp-config.php into the live site root. Per one secondary analysis, the update that installs the fix still uses the old unpacking code for that final upgrade — meaning the staging folder is briefly predictable one last time during the patching step itself (single-source; treat as a timing consideration, not a reason to delay patching).
Affected and fixed versions
| Branch | Vulnerable through | Fixed in | Branch | Vulnerable through | Fixed in |
|---|---|---|---|---|---|
| 7.1 | 7.1.3 | 7.1.4 | 5.9 | 5.9.19 | 5.9.20 |
| 7.0 | 7.0.7 | 7.0.8 | 5.8 | 5.8.18 | 5.8.19 |
| 6.9 | 6.9.10 | 6.9.11 | 5.7 | 5.7.20 | 5.7.21 |
| 6.8 | 6.8.11 | 6.8.12 | 5.6 | 5.6.22 | 5.6.23 |
| 6.7 | 6.7.10 | 6.7.11 | 5.5 | 5.5.23 | 5.5.24 |
| 6.6 | 6.6.10 | 6.6.11 | 5.4 | 5.4.24 | 5.4.25 |
| 6.5 | 6.5.13 | 6.5.14 | 5.3 | 5.3.26 | 5.3.27 |
| 6.4 | 6.4.13 | 6.4.14 | 5.2 | 5.2.29 | 5.2.30 |
| 6.3 | 6.3.13 | 6.3.14 | 5.1 | 5.1.27 | 5.1.28 |
| 6.2 | 6.2.14 | 6.2.15 | 5.0 | 5.0.30 | 5.0.31 |
| 6.1 | 6.1.15 | 6.1.16 | 4.9 | 4.9.34 | 4.9.35 |
| 6.0 | 6.0.17 | 6.0.18 | 4.8 | 4.8.33 | 4.8.34 |
| 4.7 | 4.7.38 | 4.7.39 | |||
Note: WordPress 4.6 and earlier no longer receive security updates and have no CVE-2026-119977 fix. Installations on those versions need to migrate to a maintained branch.
The final update that patches CVE-2026-119977 — the one that installs 7.1.4 — itself runs the old unpacking code one last time. According to one secondary analysis, that means the staging directory is briefly predictable during the patching step itself. The window is short and the fix is worth running. But if your site’s upgrade ran during a period of heavy attacker scanning, it may be worth reviewing logs from that specific window, not just from the period before you patched.
Threat Intelligence Breakdown
Attribution: No threat actor has been publicly named. CISA lists known ransomware use as Unknown. Neither the CVE Numbering Authority (Wordfence) nor CISA has attributed confirmed exploitation to a specific group or campaign as of November 4, 2026.
What exploitation looks like: Attackers send repeated unauthenticated HTTP requests targeting staged installer paths — specifically setup-config.php files under the wp-content/upgrade/ directory — waiting for a site upgrade to begin. Wordfence observed two large scanning operations running for more than 14 continuous hours each. Volume compensates for the short upgrade window.
Scale: Wordfence reported 20,141 blocked CVE-2026-119977 exploit attempts in the 24 hours before its November 3 review. More than 18,500 requests were logged in the first 21 hours after disclosure on October 28. These are blocked attempts, not confirmed compromises; Wordfence cited no confirmed successful exploitation as of that date.
Indicators of compromise: No IP addresses, file hashes, or domain-based indicators have been published by CISA, WordPress, or Wordfence as of November 4, 2026. Detection depends on behavioral signals:
- Unauthenticated requests to
/wp-content/upgrade/*/setup-config.phpor similar staged installer paths - Unexpected PHP file creation during or shortly after a core upgrade window
- Unexplained new administrator accounts created around upgrade timestamps
- Unusual outbound connections originating from the web server process around upgrade times
Correlate any of the above against WordPress core upgrade timestamps in server logs. A request to an upgrade path is a lead, not a confirmed compromise — it needs context.
Enterprise Impact
Scope of exposure: WordPress 4.7.0 through 7.1.3 covers the majority of active WordPress installations. Any site in that range that has run a full-package core update since the vulnerability became exploitable is a candidate for targeting, regardless of whether it is a production site, a staging environment, or a development clone.
What successful exploitation enables: An attacker who executes the staged installer gains the ability to reconfigure the WordPress database connection, which can be leveraged to overwrite or poison the database, create new administrator accounts, or redirect the site. At the server level, depending on PHP execution permissions, further compromise of the hosting environment is possible.
Managed WordPress hosts: Major hosting platforms often apply core updates automatically and in controlled windows. Organizations using managed hosting should confirm with their provider that the October 28 update was applied and ask what logging exists around the upgrade window. The answer to that second question is frequently “not much.”
Developer environments and staging sites: These often run older versions and may not have automated updates. They are as exploitable as production sites, and their credentials and database connections sometimes mirror production. Include them in the inventory.
Related coverage: See also DataWater’s earlier briefing on wp2shell CVE-2026-63030, a separate WordPress Core unauthenticated RCE from earlier in 2026, and the CISA KEV Weekly Roundup for October 30, 2026 for the broader KEV context entering this week.
What Security Leaders Should Do Next
Today
- Inventory every WordPress installation — production, staging, development, and backup clones — and record the exact core version. Use
wp core versionvia WP-CLI where available. - Update to the fixed build for your branch. Run the update through Dashboard → Updates, WP-CLI (
wp core update), or your host’s managed update mechanism. The fixed release is the only remediation; there is no published workaround. - Verify the update applied correctly: run
wp core verify-checksumsto confirm core file integrity. This covers core files only — plugins, themes, and uploads are not verified. - Review access logs around previous upgrade windows for unauthenticated requests to
wp-content/upgrade/paths. Any match warrants investigation.
Within 48 hours
- Audit administrator accounts for any created around the time of recent core upgrades that you cannot attribute to a legitimate action.
- Check for unexpected PHP files in
wp-content/upgrade/,wp-content/uploads/, and the web root that appeared around upgrade timestamps. - If anything matches: preserve logs and a copy of the environment before remediation, restrict access, rotate all WordPress admin credentials and database passwords, review scheduled tasks and plugin files for persistence, and restore from a known-clean backup if compromise is confirmed.
- Confirm managed hosting providers have applied the October 28 update and ask for evidence (version confirmation, update logs). Do not assume managed = updated.
Long-term
- Enable automatic core updates on all WordPress installations that do not have a documented reason to defer them. The October 28 patch was available the day exploitation was first observed; automatic updates would have closed the window for most sites within hours.
- Add upgrade-path monitoring to your WAF or logging stack: alert on unauthenticated requests to
/wp-content/upgrade/. This pattern has no legitimate unauthenticated use case. - Include WordPress core version in your CMDB and assign a named owner to each installation. Orphaned or forgotten WordPress sites are common and are as exploitable as production ones.
Stay ahead of the next exploited CVE
DataWater’s executive threat briefing covers the actively exploited vulnerabilities, the CISA deadlines, and the first three actions your team needs to take — before the headlines.
Winners and Losers
| Better positioned | More exposed |
|---|---|
| Organizations with automatic WordPress core updates enabled on all environments | Organizations with manual update policies and patch cycles longer than 72 hours |
| Teams that received the update on October 28 and have upgrade-path logging in place | Developers who have staging and development sites running older WordPress core versions |
| Managed WordPress hosts that applied the update automatically and can demonstrate it | Organizations using managed hosting that assume the update was applied without confirming it |
| Security teams that treat the CISA KEV as a minimum-baseline for all environments, not just federal | Teams whose KEV patch SLA exceeds the three-day federal window, with no expedite process for active exploitation |
Sites with WAF rules blocking requests to /wp-content/upgrade/ from unauthenticated users |
Sites with no WAF or perimeter logging around the WordPress web root |
Final Executive Takeaway
This is a patched vulnerability with an active exploit campaign and a federal deadline two days away.
The fixed releases have been available since October 28. The delay between patch availability and CISA’s KEV addition (six days) is not a grace period — Wordfence’s firewall matched its first exploit attempt nine minutes after the rule went live. Organizations waiting for a KEV listing before acting were already behind when November 3 arrived.
Update every WordPress installation to its branch-specific fixed version. Review logs around previous upgrade windows. If you find unexpected activity, treat it as an incident.
Frequently Asked Questions
What is WordPress Core CVE-2026-119977?
CVE-2026-119977 is a time-of-check to time-of-use (TOCTOU) race condition in the WordPress Core full-package upgrade mechanism. During a core update, WordPress unpacks the new release into a predictable, web-accessible staging path. Before the October 28, 2026 patch, an unauthenticated attacker who sent requests to that path during the brief upgrade window could execute the staged installer PHP file, potentially gaining code execution on the server. Wordfence, the CVE Numbering Authority, rates it CVSS v3.1 8.1 High.
What WordPress versions are affected by CVE-2026-119977?
WordPress Core CVE-2026-119977 affects versions 4.7.0 through 7.1.3. Every maintained branch from 4.7 onward received a branch-specific fix on October 28, 2026 — the current-line fix is WordPress 7.1.4. Versions 4.6 and earlier no longer receive security updates and have no CVE-2026-119977 fix; those installations need to migrate to a maintained branch.
Has WordPress Core CVE-2026-119977 been confirmed as exploited?
Yes. CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, 2026, confirming active exploitation. Wordfence reported 20,141 blocked exploit attempts in the 24 hours before its November 3 review, with the first attempt logged nine minutes after Wordfence deployed its firewall rule on October 28. As of November 4, Wordfence had not confirmed a successful compromise in published reporting.
What is the CISA deadline for CVE-2026-119977?
CISA added WordPress Core CVE-2026-119977 to the Known Exploited Vulnerabilities catalog on November 3, 2026, with a remediation deadline of November 6, 2026 for all Federal Civilian Executive Branch agencies under Binding Operational Directive 22-01. That is two days from the publication of this briefing.
What is the fix for WordPress CVE-2026-119977 and is there a workaround?
The fix for CVE-2026-119977 is to update to the branch-specific fixed WordPress release — 7.1.4 for the current branch, or the equivalent fix for your installed version (see the versions table above). WordPress has not published a separate workaround; the fixed release is the required endpoint. If an immediate update is impossible, limiting web access to the wp-content/upgrade/ directory via server configuration or WAF rules reduces exposure, but this is a temporary measure and must be verified not to break legitimate maintenance.
What are the indicators of compromise for WordPress CVE-2026-119977?
No IP addresses, file hashes, or domain-based indicators have been published for WordPress CVE-2026-119977 as of November 4, 2026. Detection relies on behavioral signals: unauthenticated HTTP requests to setup-config.php files under the wp-content/upgrade/ staging path, unexpected PHP file creation around core upgrade timestamps, unexplained new administrator accounts, and unusual outbound connections from the web server process during upgrade windows. Cross-reference any suspicious requests with WordPress core update timestamps in server logs.
How is CVE-2026-119977 different from the earlier WordPress zero-day CVE-2026-63030?
CVE-2026-119977 and CVE-2026-63030 (wp2shell) are distinct WordPress Core vulnerabilities with different mechanisms, different affected code paths, and different affected version ranges. CVE-2026-63030 was an unauthenticated RCE covered in DataWater’s earlier briefing at datawater.com/wp2shell-cve-2026-63030/. CVE-2026-119977 specifically targets the core upgrade mechanism’s staging paths and affects WordPress 4.7.0 through 7.1.3. Being patched for CVE-2026-63030 does not mean you are protected against CVE-2026-119977.
Sources
Primary sources: GitHub Advisory GHSA-4w3m-c66w-69mg (WordPress Core CVE-2026-119977 record, Wordfence CNA); CISA Known Exploited Vulnerabilities catalog (November 3, 2026 addition). Secondary reporting reviewed: The Hacker News (November 3, 2026), Wordfence (live threat feed, November 3 review), aicybr.com (version table and CVSS), cipherssecurity.com (exploitation detail and fix mechanism), windowsforum.com (KEV coverage). Reflects public reporting as of November 4, 2026.
