CVE-2026-119977

Is it being exploited? CISA lists CVE-2026-119977 in its Known Exploited Vulnerabilities catalog (added November 3, 2026). CISA's entry reads: "WordPress WordPress Core contains a time-of-check time-of-use (TOCTOU) race condition vulnerability that could allow unauthenticated attackers to execute code on the server during the upgrade window. This is due to predictable, web-accessible staging paths used during full-package core upgrades." CISA lists ransomware use as "Unknown" and flags the entry for forensic triage. WordPress's 7.1.4 release post does not mention exploitation. We found no public proof of concept on GitHub.

What's affected and fixed.

• Affected: WordPress Core 4.7 through 7.1.3 (NVD, from Wordfence as CNA), on every branch below its fixed release.
• Fixed in 7.1.4, released October 28, 2026. WordPress describes the fix as "A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window," reported by Umut Bayram.
• Backports on WordPress's releases page, dated October 28, 2026: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15 and 6.1.16.
• Backports offered by WordPress's update API (checked November 3): 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34 and 4.7.39.
• Each fixed release is one above the last affected version for its branch in the CNA's data on NVD. WordPress's release post says "The backports are in progress and will ship as they become ready," and that "only the most recent version of WordPress is actively supported."
• WordPress below 4.7 is outside the affected range and receives no security fixes.

The test. Is the site's core version below the fixed release for its branch? If yes, it is reachable whenever a full-package core upgrade runs. If it is at or above the fixed release, this CVE is closed going forward.

1. Check the version. wp core version with WP-CLI, grep wp_version wp-includes/version.php on disk, or Dashboard, then Updates, in the admin.
2. Check whether core upgrades run. NVD says the exposure exists "during the upgrade window," so the window opens during the update itself, including the update to the fixed release. WordPress's wp-config documentation lists define( 'WP_AUTO_UPDATE_CORE', 'minor' ); as "Enable core updates for minor releases (default)," and documents define( 'AUTOMATIC_UPDATER_DISABLED', true ); to disable automatic updates; check wp-config.php for both. WordPress's 7.1.4 post says: "If you have sites that support automatic background updates, the update process will begin automatically." Manual updates from the dashboard or wp core update also run the core upgrader.

Our reading of the update window (Tuskira's reading of the code change, not a WordPress statement). Because minor releases install automatically by default, most sites likely updated to 7.1.4 after October 28. That update ran through the pre-fix upgrader shipped in the installed, vulnerable version, so those sites likely went through the upgrade window at least once during the period CISA lists the flaw as exploited. Being on 7.1.4 now closes the flaw for future updates; it does not by itself tell you what happened during that one update.

Staging path, from WordPress core source. In 7.1.3, WP_Upgrader::unpack_package() in wp-admin/includes/class-wp-upgrader.php unpacks packages into wp-content/upgrade/ under a directory named after the package file. In 7.1.4, the same function adds get_working_dir_name(), documented in the source as building "an unpredictable name for the directory a package is unpacked into" by appending a random 16-character string. NVD's references also point to class-core-upgrader.php, update-core.php and setup-config.php. That the attack goes through this directory is our reading of the code diff; WordPress has not published a technical write-up.

WordPress publishes no mitigation for CVE-2026-119977, and CISA's required action is to apply vendor mitigations, so we list no controls here. Disabling automatic updates would avoid an upgrade window but also delays the fix, and no source recommends it as a mitigation.

Updating to a fixed release is the only fix.

Neither WordPress nor CISA has published indicators of compromise for CVE-2026-119977.

My site already auto-updated to 7.1.4. Could it have been exploited during the update?

Our reading (Tuskira's reading of the code change, not a WordPress statement): possibly. The update to 7.1.4 ran through the pre-fix upgrader, so the site went through the upgrade window once while CISA lists the flaw as exploited. The same applies to any site that updated late. CISA's KEV entry carries its forensic triage flag, and its required action reads: "Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA's BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA's “Forensics Triage Requirements” (see URL in Notes)." CISA's BOD 26-04 implementation guidance lays out six forensic triage steps: scoping; preserve and collect evidence; critical patching and stabilization; contain and control; triage analysis; and an escalation decision. It says KEV may include specific triage steps for a CVE; the entry for this CVE lists none. Neither WordPress nor CISA has published compromise checks for CVE-2026-119977.

Am I exposed to CVE-2026-119977?

If your WordPress Core version is 4.7 through 7.1.3 and below the fixed release for its branch, and a full-package core upgrade runs, NVD says the server is open to unauthenticated code execution "during the upgrade window."

Is CVE-2026-119977 being exploited?

CISA added it to the KEV catalog on November 3, 2026. CISA's entry: "WordPress WordPress Core contains a time-of-check time-of-use (TOCTOU) race condition vulnerability that could allow unauthenticated attackers to execute code on the server during the upgrade window." Ransomware use is listed as "Unknown."

Is there a patch for CVE-2026-119977?

Yes. WordPress 7.1.4 (October 28, 2026), backports 7.0.8 through 6.1.16 on WordPress's releases page, and 6.0.18 through 4.7.39 offered by WordPress's update API.

How do I mitigate CVE-2026-119977 without patching?

WordPress publishes no mitigation. Updating to a fixed release is the only fix.

Nov 3, 2026. First published, the day CISA added CVE-2026-119977 to KEV, due Nov 6.

• WordPress 7.1.4 security release (Oct 28, 2026)
• WordPress releases and the WordPress core update API (version-check, checked Nov 3)
• WordPress core source, class-wp-upgrader.php at 7.1.3 and 7.1.4
• WordPress wp-config documentation
• NIST NVD: CVE-2026-119977 (Undergoing Analysis; Wordfence's 8.1 only, checked Nov 3)
• CISA Known Exploited Vulnerabilities catalog (added Nov 3, due Nov 6) and CISA's BOD 26-04 implementation guidance, linked from the entry's notes