WordPress CVE-2026-119977: update-window RCE

Most WordPress emergencies come from plugins. This one is in core, and it has an odd shape: the vulnerable moment is the update itself. On 3 November 2026 CISA added CVE-2026-119977 to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline of 6 November. The catalog marks it for forensic triage, which means CISA wants affected owners to look for compromise, not only to patch.

WordPress shipped the fix in 7.1.4 on 28 October. If your sites auto-update, many are already on it. The ones to worry about are the ones that don't.

What the vulnerability is

From the CVE record (assigned by Wordfence as the CNA) and the CISA entry:

• Component: WordPress core, during a full-package core upgrade.
• Weakness: a time-of-check time-of-use race (CWE-367). During the upgrade, WordPress stages the new files at a predictable path inside the web-served upgrade folder.
• Impact: an unauthenticated attacker who requests the right staged file while it exists can execute code on the server.
• Affected: 4.7 through 7.1.3.
• Score: CVSS 3.1 8.1, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The "high" attack complexity is the timing: the window is open only while an update is running.
• Credit: Umut Bayram, per the WordPress release notes.

Two severities, one bug

The WordPress project's own advisory, GHSA-4w3m-c66w-69mg, rates the issue Low. The CVE record says High (8.1). CISA says it is being exploited. These aren't really in conflict. The vendor is scoring how hard the race is to win against any one site. CISA is reporting that attackers are trying anyway, at scale, across many sites at once. An attack that only works for a few seconds per site is still worth running when you can aim it at a very large number of sites and wait for one of them to update.

Treat the KEV listing as the deciding fact. A "Low" label from the vendor is not a reason to defer a patch that is being used in the wild. We made the same argument more generally in why a CVSS score alone is not a priority.

Fixed versions

The fix is in 7.1.4 and was backported to every branch that still takes security fixes, back to 4.7. From the GitHub advisory:

Branch	First fixed version
7.1	7.1.4
7.0	7.0.8
6.9	6.9.11
6.8	6.8.12
6.7	6.7.11
4.7 to 6.6	see the advisory's full list

Two cautions. First, the backports shipped after the 28 October release, so check that your branch's fixed version is actually installed before you assume it is. Second, WordPress says only the most recent version is actively supported. A backport closes this one bug; it doesn't make an old branch a supported one. If you are below 7.1, plan the move to 7.1.4.

7.1.4 also fixes a dozen other issues, mostly stored XSS in blocks, the Interactivity API and the Customizer, plus a bundled root-certificate update. That is another reason not to cherry-pick.

What to do, in order

1. List every WordPress install you own. The main marketing site is the easy one. The risk is in the rest: a campaign microsite, a staging copy, a docs or careers site an agency built, a blog on a subdomain. Our earlier wp2shell write-up has the same step for the same reason.
2. Check the version in the dashboard under Dashboard → Updates, or with wp core version if you have WP-CLI.
3. Update to 7.1.4, or to the fixed release on your branch.
4. Don't update in a loop on an exposed site and walk away. The bug lives in the update window. Until a site is on a fixed version, every full core update it runs is a window. Where you can, run the update to the fixed version in a quiet period, or with the site behind maintenance access.
5. Consider blocking web access to wp-content/upgrade/. This is our suggestion, not WordPress's instruction: WordPress unpacks updates there but doesn't need visitors to load files from it. A deny rule in your web server or CDN is a small change. Test an update afterwards. It is hardening, not a substitute for the patch.
6. Look for signs it already happened. CISA flagged this one for forensic triage. Check web server logs since late October for requests to paths under wp-content/upgrade/, especially ones ending in setup-config.php. Look for new admin users, unfamiliar plugins and PHP files that don't belong to core, your theme or a known plugin.
7. If you find anything, assume the site's secrets are gone. Rotate the database password and the keys and salts in wp-config.php, reset admin passwords, and check what else that host could reach.

Where CyberSpec fits, and where it doesn't

CyberSpec does not test for CVE-2026-119977, and it does not try to exploit anything. What a full scan of your verified domains does is identify the technology a web host is running, WordPress included, with the version when the site exposes it. That version is then checked against endoflife.date and marked End of life (high) or Outdated version (medium) when it is behind. New detections also go into the daily digest email, so a forgotten WordPress install on a domain you have added shows up on a list you can work through.

There are limits. Many WordPress sites hide their version, and then the scan can say "WordPress" but not "7.1.3". An outdated verdict also depends on endoflife.date having recorded the newest release. The check on the dashboard, and the update itself, still happen in WordPress. For more on how the two verdicts differ, see outdated vs end-of-life software.

See how vulnerability management works.