CVE-2026-119977: WordPress Core Upgrade-Window TOCTOU Race Allows Unauthenticated Remote Code Execution

Background

A flaw in WordPress Core, unlike one in a plugin, does not depend on which theme or plugins a site runs; our assessment is that it reaches any site on an affected version. CVE-2026-119977 sits in the Core upgrade machinery, the code that downloads a release package, stages its files and swaps them into place when an administrator (or a background auto-update) upgrades the site.

According to NVD, which repeats the CNA description, the upgrade routine uses “predictable, web-accessible staging paths” during full-package core upgrades. That lets an unauthenticated attacker execute code on the server during the upgrade window. The WordPress 7.1.4 release post, dated 28 October 2026, lists “a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window”, credited to Umut Bayram. The post itself does not name a CVE ID. The link to CVE-2026-119977 comes from the KEV and NVD records, which both reference that post.

Technical Mechanism

CISA classifies the flaw as CWE-367 (Time-of-check Time-of-use Race Condition). The CVE record says the problem is predictable staging locations that can be reached over HTTP while an upgrade runs. We read that as the following attack shape. This is our reading of the public description, not a code-level analysis, and we have not reproduced the bug:

1. The site starts a full-package core upgrade, manually or through automatic background updates.
2. Core writes upgrade or installer files to a staging location whose path an attacker can predict and request over the web.
3. During the window before those files are removed or moved, an unauthenticated request reaches code in that staging area, and the attacker’s input runs as PHP in the web server’s context.

The vector rates attack complexity High, which is consistent with the attacker needing to act while an upgrade is in flight (our reading; the record does not explain the rating). The NVD references point at lines in Core upgrade-path files (class-core-upgrader.php, class-wp-upgrader.php, update-core.php and setup-config.php in the 7.1.3 tag, and class-wp-upgrader.php and update-core.php in the 7.1.4 tag), but we did not diff them.

The published CVSS vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, base score 8.1 (High). It comes from Wordfence ([email protected]), listed by NVD as a Secondary source. NVD’s own analysis was still marked “Undergoing Analysis” when we checked on 4 November 2026, so there is no NVD-primary score yet.

Real-World Exploitation Evidence

CISA added CVE-2026-119977 to the Known Exploited Vulnerabilities catalog on 3 November 2026 with a due date of 6 November 2026, three days later, and marked it for forensic triage under BOD 26-04. KEV lists knownRansomwareCampaignUse as “Unknown”. NVD also carries a CISA SSVC record dated 3 November 2026 with exploitation “active”, automatable “no” and technical impact “total”.

CISA’s entries do not name a threat actor, campaign, victim set or exploit source, and we found none. As of 4 November 2026 we found no public proof-of-concept or exploitation write-up in the NVD references, the WordPress release post or the CISA record. Wordfence’s advisory page did not load for us, so anything it says about attack telemetry is not reflected here. The SSVC “exploitation: active” value is CISA’s assessment; we found no victim or telemetry detail behind it.

Impact Assessment

Successful exploitation gives code execution as the web server user, which on typical WordPress hosting means read access to wp-config.php (database credentials and secret keys), write access to the site’s files, and the ability to plant web shells, create administrator accounts or pivot to the database.

The exposure is tied to timing, and our assessment is that two kinds of sites matter most:

• Sites with automatic background core updates, where upgrades happen without an administrator watching.
• Managed hosting and agency fleets that upgrade many sites in a burst, which creates many upgrade windows an attacker can probe.

Because the flaw is only reachable during an upgrade, a site that is not upgrading is not exposed through this path. Our inference, not stated by the vendor: the upgrade to 7.1.4 is itself run by the installed, older upgrader code, so that upgrade window may still be exposed.

Affected Versions

The affected range is from the NVD description (via the CNA) and the Wordfence advisory URL. We did not independently test any version. The per-branch releases in the last row are the latest versions the WordPress.org version-check API offered on 4 November 2026. They match one patch above NVD’s per-branch affected ceilings, but this is our reading from a single source, not a vendor advisory, so confirm that your branch’s release is listed as a security release before relying on it. WordPress 7.2 Beta 3 also carries the fixes, but is a pre-release.

Remediation Steps

1. Update to WordPress 7.1.4, or to the newest release for your branch (see Affected Versions) through the dashboard (Dashboard > Updates) or WP-CLI (wp core update). The release post recommends updating immediately.
2. Do the upgrade in a controlled window. Because the exposure exists while the upgrade runs, avoid running it on a site that is open to the internet without protection if you can: use a maintenance mode, or restrict inbound access at the web server or WAF during the upgrade. This is our guidance, not vendor advice.
3. Check automatic update status. If background updates are enabled, confirm the site actually reached 7.1.4 (wp core version).
4. For federal civilian agencies, the KEV due date is 6 November 2026 under BOD 26-04. Others should treat that date as a sensible target.
5. If you cannot update, CISA’s required action is to apply mitigations per vendor instructions or discontinue use of the product if none are available. We found no vendor-published workaround as of 4 November 2026 in the NVD record, the WordPress 7.1.4 release post or the CISA entry.

Detection Guidance

As of 4 November 2026 we found no published IOCs for this CVE (no IPs, hashes or file names) in the NVD record, the WordPress 7.1.4 release post or the CISA entry, and none are given here.

• Look at the upgrade window. Correlate WordPress upgrade events (WP-CLI logs, wp-content/upgrade/ directory activity, auto-update cron runs) with web-server access logs for the same period. Unusual unauthenticated requests to paths under wp-content/upgrade/ or to unexpected PHP files in the site root during an upgrade deserve review.
• Check for leftovers. Look for unfamiliar PHP files in wp-content/upgrade/, wp-content/ and the web root, and for files with modification times that fall inside an upgrade window. Compare core files against checksums with wp core verify-checksums.
• Review accounts and options. Check for new administrator accounts, changed siteurl/home options and unknown scheduled events.
• Hunt for post-exploitation. Watch for web-server processes spawning shells, outbound connections from the PHP process and reads of wp-config.php.
• KEV triage. CISA flagged this entry for forensic triage, so our assessment is that internet-exposed sites that ran a core upgrade while still on an affected version should be examined, not only patched. We cannot give a start date for exploitation; the only dates we have are the 28 October fix release and the 3 November KEV listing.

These checks are our suggestions based on the vulnerability class, not vendor or CISA detection content.

Timeline

References

• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-119977
• WordPress 7.1.4 release post: https://wordpress.org/news/2026/10/wordpress-7-1-4/
• CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-119977
• CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk