CVE-2026-119977 turns a normally routine WordPress core update into a short but dangerous exposure: while a full package is being staged, an unauthenticated attacker can race the upgrade process and get code to run on the web server. WordPress released the fix in 7.1.4 on October 28, 2026, before the CVE record was published on October 31.
WordPress Core is the free, self-hosted PHP content-management software behind websites, blogs, stores, portals and multisite networks—not the managed WordPress.com service. That puts the issue in front of everyone from individual site owners and agencies to hosts, publishers, retailers, nonprofits, universities, government teams and enterprises that run WordPress on their own infrastructure.
Predictable staging names make the race possible
A full core upgrade downloads and unpacks a package into a temporary working directory before moving files into the live installation. In affected releases, that directory name was derived predictably from the package filename and was reachable from the web. An attacker did not need a WordPress account: they needed to repeatedly request or write to the expected path at precisely the interval between the upgrade process checking a condition and using its result. That is the time-of-check/time-of-use race.
The consequence is server-side code execution, with the practical privileges of the web-server process and whatever it can reach: site files, application secrets, databases through configured credentials, and potentially other systems depending on host isolation. The window is brief and depends on a core upgrade actually occurring, which explains the high attack complexity; it does not make an exposed, actively updating fleet a comfortable risk.
The repaired code makes the staging directory unguessable by adding a random 16-character suffix:
private function get_working_dir_name( $package ) {
// Strip off any .tmp or .zip suffixes.
$name = basename( basename( $package, '.tmp' ), '.zip' );
return $name . '-' . wp_generate_password( 16, false );
}The patch also prevents directory listing from revealing that name and ensures a staged wp-config.php is not copied into the live site.
Exploitation is active; patch before the next upgrade
Exploitation attempts are confirmed. CVE-2026-119977 was added to CISA’s Known Exploited Vulnerabilities catalogue on November 3, with a November 6 federal remediation deadline; the CVE record records active exploitation. Observed activity includes sustained polling of installer and staging paths, and telemetry has recorded blocked requests.
No named victim, confirmed public breach, threat actor or coordinated campaign has been documented in the reviewed material. Nor has a public working proof of concept surfaced; analysis of the issue distinguishes public source-level detail from usable exploit code.
Update immediately to 7.1.4, or to the security maintenance release supplied for the branch you operate: fixes were backported from 4.7.39 through 7.0.8, with 7.1.4 fixing the current branch. Treat 4.6 and earlier as unsupported rather than assuming a backport exists. Before and after patching, review web and WAF logs for repeated requests to upgrade directories, installer files such as setup-config.php, and unexpected PHP or wp-config.php changes around upgrade times; isolate and investigate any hit rather than treating it as ordinary scanning.
For teams with many sites, inventory which installations actually self-host WordPress and make upgrade monitoring an operational control, not an occasional chore. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs; here, the immediate job is to remove the vulnerable upgrade window before attackers can time it.
