The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-119977, a flaw in WordPress core, to its Known Exploited Vulnerabilities (KEV) catalog on November 3, 2026. The bug is a time-of-check/time-of-use race in the way WordPress stages its own core updates. The CVE record says it affects WordPress 4.7 through 7.1.3 and lets an unauthenticated attacker run code on the server while an update is in progress. WordPress fixed it in 7.1.4, released October 28.
Why it matters: this is not a plugin bug that only some sites have. It is in core, it spans every release from 4.7 to 7.1.3, and the vulnerable moment is the update itself. A KEV listing means CISA has evidence of exploitation in the wild. CISA's alert does not name an attacker or say how many sites were hit, according to WindowsForum's write-up of the alert.
The flaw in one paragraph
When WordPress installs a full core update, it unpacks the new release into a working folder under wp-content/upgrade/. According to Ostorlab's technical analysis, that folder name was derived only from the package filename, so an attacker could predict it. The unpacked copy includes the setup wizard, setup-config.php, and since release packages ship without a wp-config.php, the wizard's "already installed" check passes. An attacker who requests the staged wizard in the seconds the folder exists can point it at a database they control and reach PHP execution as the web server user. Ostorlab says that on unpatched versions, an attacker-written config file could also be copied to the site root and persist after the update finishes. The 7.1.4 fix adds a random suffix to the staging folder.
Severity: high on paper, hard to win in practice
| CVE | CVE-2026-119977 (CWE-367, TOCTOU race) |
| Affected | WordPress core 4.7 – 7.1.3 |
| Fixed | 7.1.4 (Oct 28, 2026), plus backports to older branches |
| CVSS 3.1 | 8.1 High (AV:N/AC:H/PR:N/UI:N) |
| Auth needed | None |
| CISA KEV | Added November 3, 2026 |
| Credited reporter | Umut Bayram |
The "AC:H" (high complexity) in the score reflects the race: the window lasts seconds, so attackers have to poll repeatedly and get lucky. Ostorlab notes WordPress itself rates the issue Low, while Wordfence scores it 8.1. Before the KEV listing, Ostorlab reported that Wordfence had blocked 62,969 requests targeting the flaw in the 24 hours to October 30, with some sources polling small groups of sites for about 14.5 hours. Those were blocked attempts; at that point no confirmed compromise had been reported. CISA's listing three days later is the first signal that attempts have turned into real exploitation.
The race fix was one of 18 items in the 7.1.4 release notes. The same release also fixes a batch of stored cross-site scripting bugs, several of them in the Interactivity API.
What to do
- Check your version, don't assume. In wp-admin go to Dashboard → Updates. You want 7.1.4 or later. Automatic background updates should have delivered it, but confirm on every site, including staging copies and installs on managed hosts.
- On an older branch? WordPress backported fixes to branches back to 4.7 (for example 7.0.8, 6.9.11, 6.8.12, 6.7.11), but the release notes show older branches did not receive all 22 fixes, and only the newest version is actively supported. The safe move is 7.1.4.
- Block web access to
wp-content/upgrade/at the web server (nginx or Apache) if you can't update immediately, and keep the block in place while you run the update, since the update itself opens the window. Ostorlab notes theindex.phpfile added by the fix only stops directory listing, not direct requests. This is analyst guidance, not an official WordPress instruction. - Look for signs of a hit. Search access logs for requests to PHP files under
wp-content/upgrade/, especiallysetup-config.php. Any PHP file left in that folder other than the placeholderindex.php, especially awp-config.php, deserves a closer look, as do unfamiliar admin accounts or plugins. - Clean up leftovers in
wp-content/upgrade/that the updater didn't remove.
U.S. federal civilian agencies are required to prioritize KEV entries on public-facing systems. Everyone else running self-hosted WordPress should treat this as a same-day check: the fix has been out since October 28, and Wordfence's numbers show attackers were probing for this within days of the release.
Sources
- WordPress.org — Version 7.1.4 release notes wordpress.org
- cvefeed.io — CVE-2026-119977: WordPress Core upgrade-window staged-installer RCE cvefeed.io
- Ostorlab — WordPress core upgrade-window RCE, fixed in 7.1.4 (CVE-2026-119977) blog.ostorlab.co
- WindowsForum — CISA flags WordPress CVE-2026-119977 as actively exploited windowsforum.com