CVE-2026-119977 WordPress update race RCE: now exploited

Update, Nov 9: The update that installs the fix can be the last attack window. Picus Security’s Umut Bayram found that the update to 7.1.4 still unpacks with the site’s old, unpatched updater, and on 5.9 and later that old code names the staging folder after the downloaded file, so it’s predictable one more time. Catch that window and you can set up the staged copy with your own database and run PHP as the web server. (The wp-config.php overwrite trick is already blocked during that update, because the files get copied into place by the new code.) Whether a given site is exposed depends on whether its update package contains the installer files: complete packages always do, and a partial package only sometimes. The Hacker News found WordPress.org offering partial packages for in-branch moves like 7.1.3 to 7.1.4, and complete ones for cross-branch moves like 7.0.7 to 7.1.4. Sites already on 7.1.4 or a branch fix are done: later updates use a random folder name. For everyone else, the order matters: block web access to wp-content/upgrade/ first, confirm it returns 403, then update. On Nginx that’s location ^~ /wp-content/upgrade/ { deny all; }; on Apache, Require all denied for that folder in the vhost, or RedirectMatch 403 ^/wp-content/upgrade/ in the root .htaccess above the rewrite rules. Don’t drop an .htaccess inside wp-content/upgrade/ itself, because the old updater empties that folder first. wp core update is no way around it, since WP-CLI uses the same updater. The other safe route is a manual update unpacked outside the web root. (The Hacker News (opens in a new tab), Picus (opens in a new tab))

Update, Nov 4: The call goes from Deploy to Patch now. On Nov 3, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog “based on evidence of active exploitation,” with a federal deadline of Nov 6 and forensic triage required (CISA (opens in a new tab)). CISA didn’t say what it saw. Nobody has publicly described a successful compromise yet, and TrendAI’s write-up from the same week still says none was reported as of Nov 3. The attempts haven’t let up, though: BleepingComputer quotes Wordfence blocking 13,095 attacks in 24 hours, and TrendAI counts 13,835 in the 24 hours to Nov 3. The backports are also done. TrendAI lists 7.1.4, 7.0.8, 6.9.11 and a matching release for every branch back to 4.7.39, all out Oct 28 and 29. Versions 4.6 and older get nothing. (BleepingComputer (opens in a new tab), TrendAI (opens in a new tab))

Call: Patch now. WordPress 7.1.4 (Oct 28) is a security release with fixes for 22 issues. The one to care about is a race condition in the core update process that can lead to remote code execution without a login. CISA now lists it as exploited. Make sure 7.1.4, or your branch’s fixed release, actually landed, and look at your logs while you’re there.

What breaks: During a full core update, WordPress unpacks the new files into a predictable staging directory that’s reachable from the web on many servers. An attacker who hits that directory in the few seconds before WordPress cleans up can abuse the staged installer, setup-config.php, which runs because the staged copy has no wp-config.php. Wordfence (Defiant) rates the attack complexity high, because the attacker has to catch that window. Attackers are making up for it with volume. 7.1.4 randomizes the staging directory, adds an index guard, and stops staged configuration data from being promoted unsafely. The CVE was assigned by Wordfence on Oct 30 and rated 8.1 (High). WordPress itself rates it Low.

What’s been seen: Defiant says its firewall rule got its first hit nine minutes after it went live, and it logged more than 18,500 requests for staged installer paths in the first 21 hours. CISA added the CVE to KEV on Nov 3.

Who’s hit: Self-hosted WordPress sites on 4.7 through 7.1.3 that run a full-package core update. The window opens during the update itself, so sites that update automatically are exposed at the moment they update, not before.

What to do:

Update to 7.1.4, or the fixed release for your branch. Sites with automatic background updates should already have it. Check the version anyway.
Block web access to wp-content/upgrade/ before you update, and confirm it returns 403. The update to 7.1.4 itself is the window (see the Nov 9 update above).
Check your logs for requests to PHP files under wp-content/upgrade/, especially setup-config.php, around the time your site updated. CISA wants federal agencies to do forensic triage on this one, which is a reasonable bar for anyone else too.

7.1.4 also updates WordPress’s bundled root certificates to drop the compromised eMudhra CAs.

Sources: CISA KEV alert (opens in a new tab), BleepingComputer (opens in a new tab), TrendAI (opens in a new tab), WordPress 7.1.4 (opens in a new tab), SecurityWeek (opens in a new tab), CVE-2026-119977 (opens in a new tab).

CVE-2026-119977 WordPress update race RCE: now exploited

Sources

More from October 2026 patch cycle