CISA added CVE-2026-119977, a time-of-check/time-of-use (TOCTOU) race condition in WordPress Core’s full-package upgrade routine, to its Known Exploited Vulnerabilities catalog on November 3, 2026. The flaw affects every release from 4.7.0 through 7.1.3 and can yield unauthenticated code execution on a server while it is mid-upgrade. Federal civilian agencies have until November 6 to remediate.

What happened

WordPress 7.1.4 shipped on October 28, 2026 as a security release covering 22 vulnerabilities, with backports for older branches (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, and onward down to 4.7.39). One of those fixes closes CVE-2026-119977. Reporting indicates exploitation attempts were observed as early as October 30, two days after the release, consistent with attackers diffing the patch. Public exploit material was reported to be appearing by November 4. Indicators of compromise have not been broadly published, and ransomware use is listed as unknown.

Technical details

During a full-package core upgrade, WordPress downloads the release archive and extracts it into a staging location under wp-content/upgrade/. Prior to 7.1.4 the staging directory names were predictable and the directory was reachable over HTTP on default configurations. An unauthenticated attacker who can guess the path and win the timing window between the extraction step and the cleanup/promotion step can request staged PHP files, or influence staged configuration data, and get it executed by the web server.

According to published analyses, 7.1.4 changes three things:

  • Staging folder names are now randomized rather than predictable.
  • An index guard is placed in the staging directory so it cannot be listed or served.
  • Staged configuration data is no longer promoted into the live install.

The bug class matters for how you should rate it. Exploitation is timing-dependent and only works against a site that is actively upgrading, which is why severity ratings diverge: Wordfence (the CNA) scores it CVSS 8.1 High, WordPress itself rates it Low, and Patchstack has argued the window is too short to be practical. CISA’s KEV listing is evidence that, at least against some targets, the window is practical enough. Sources also disagree on the CWE mapping (CWE-367 in most, CWE-362 in one), so verify against the NVD record.

The practical risk is higher than the “short window” suggests in two situations: sites with auto-updates enabled, where an attacker can poll continuously and trigger or wait for the upgrade cycle on a schedule; and slow or resource-constrained hosts, where extraction takes long enough to widen the race considerably. Mass-hosting providers that stagger auto-updates across thousands of tenants are an attractive target for scripted polling.

Impact

Any self-hosted WordPress from 4.7 onward that performs full-package upgrades is in scope, which is effectively the entire installed base that has not yet moved to 7.1.4 or a backported release. Successful exploitation gives the attacker code execution as the web server user: webshell placement, wp-config.php database credential theft, admin account creation, and a foothold for lateral movement on shared hosts. Managed WordPress platforms that patched centrally are largely unaffected.

Mitigation

  1. Update to WordPress 7.1.4 or the corresponding backport for your branch (for example 7.0.8 or 6.9.11). Do this before the November 6 KEV deadline if you are a federal agency or contractor.
  2. Block web access to wp-content/upgrade/ at the web server or WAF until you are patched. In nginx, location ^~ /wp-content/upgrade/ { deny all; }; in Apache, a Require all denied in a .htaccess for that directory.
  3. Don’t leave the updater half-staged. If an upgrade fails or hangs, clear wp-content/upgrade/ and .maintenance and re-run it rather than leaving the partially extracted tree exposed.
  4. Hunt for exploitation. Review access logs since October 28 for unauthenticated requests to /wp-content/upgrade/ paths, especially bursts of requests that correlate with upgrade events. Look for unexpected PHP files in wp-content/, new administrator users, and modified wp-config.php or wp-content/mu-plugins/ entries.
  5. Schedule upgrades deliberately. For high-value sites, disable background core auto-updates until patched, then upgrade during a maintenance window with the upgrade directory denied at the edge.

References