CVE-2026-119977WordPress Core race condition in the upgrade window

Executive summary

A time-of-check time-of-use race condition in the WordPress Core updater lets an unauthenticated attacker execute code while a full core upgrade is running, caused by a predictable, web-accessible staging path.

The issue is fixed in WordPress 7.1.4, released on 2026-10-28. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-11-03 after exploitation was observed on 2026-10-30.

Threat assessment

The attack needs no authentication, but it only works during the short window in which a full core upgrade is running. Sites that upgrade automatically or on a predictable schedule give an attacker a more reliable window.

Exploitation is confirmed and the vulnerability is in CISA KEV. We rate the threat level as Critical despite the CVSS 8.1 High score because of confirmed exploitation and the size of the WordPress install base.

Timeline

1. 2026-11-04

   CISA updates its alert.

2. 2026-11-03

   Added to CISA KEV, federal deadline 2026-11-06. Canadian Cyber Centre publishes advisory AV26-1117.

3. 2026-10-31

   CVE record published. WordPress Core through 7.1.3 affected, CVSS 8.1.

4. 2026-10-30

   First exploitation observed.

5. 2026-10-28

   WordPress 7.1.4 security release.

Affected & exposure

WordPress Core 4.7 through 7.1.3 (Wordfence). Fixed in 7.1.4; same-day backports for older branches include 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 and down to 4.7.39. Sites on 4.6 or older receive no fix (Patchstack).

Exposure: any internet-facing WordPress site on an affected version that runs a full core upgrade, including unattended background updates. No public internet-wide count of exposed sites has been published.

Exploitation in the wild

Exploitation was first observed on 2026-10-30, two days after the fixed release and one day before the CVE record was published.

Wordfence blocked 62,969 exploitation attempts in the first 24 hours after the 7.1.4 release, the first nine minutes after its firewall rule went live, and reported 13,095 blocked attacks in a later 24-hour period. The requests target the staged installer (wp-admin/setup-config.php inside wp-content/upgrade/) directly, cycling through version names and staging paths. Wordfence has not reported a confirmed successful compromise, and no attacker IPs or payload hashes have been published.

Detection & hunting

Hunt for requests to the upgrade staging path during and around upgrade windows.

index=web sourcetype=access_combined uri_path="*/wp-content/upgrade/*"
| eval installer=if(like(uri_path, "%setup-config.php%"), 1, 0)
| stats count sum(installer) AS installer_hits values(method) AS methods values(status) AS statuses min(_time) AS first_seen by src_ip host
| convert ctime(first_seen)
| sort - installer_hits count

title: Request to WordPress upgrade staging path
status: experimental
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|contains: '/wp-content/upgrade/'
  condition: selection
level: high

Mitigation

• Update WordPress Core to 7.1.4 or the patched release of your branch.
• Block web access to wp-content/upgrade/ at the web server and make sure directory listing is disabled (Patchstack). A PHP-level security plugin does not protect this path, because the extracted copy does not load the site's WordPress instance.
• Review recent upgrade windows: between updates, wp-content/upgrade/ should contain only index.php. Check it and the document root for unexpected PHP files, look for a wp-config.php or database settings pointing to a host you do not control, and search web logs for requests to setup-config.php below wp-content/upgrade/.

Update log

Sources

1. CISA Known Exploited Vulnerabilities Catalog
2. NVD - CVE-2026-119977
3. Canadian Centre for Cyber Security - Alerts and advisories
4. WordPress News - Releases
5. Patchstack: WordPress 7.1.4 security release
6. BleepingComputer: CISA flags WordPress RCE flaw as actively exploited