WordPress CVE-2026-119977 is on CISA's KEV list: finish 7.1.4 now

If you still owe your personal WordPress site the 7.1.4 security update, stop treating it as optional. On November 3, 2026, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) Catalog. That is the agency’s public signal that this WordPress Core bug is being exploited, not just theoretically interesting.

We already covered the release itself in WordPress 7.1.4: update your personal site for 22 security fixes. This page is the follow-up: CISA’s KEV listing, what the flaw actually is in plain language, and the short checklist for a home or hobby site.

What CISA listed on November 3

CISA’s alert names:

• CVE-2026-119977
• WordPress Core Time-of-check Time-of-use (TOCTOU) race condition vulnerability

CISA’s KEV catalog entry describes a race during full-package core upgrades: predictable, web-accessible staging paths can let an unauthenticated attacker execute code on the server during the upgrade window. CISA marked forensic triage as required for federal agencies under BOD 26-04, with a federal due date of November 6, 2026. That deadline is for U.S. federal civilian agencies. CISA still encourages everyone else to prioritize KEV items.

BleepingComputer’s November 4 report says Wordfence reported blocking 13,095 attacks aimed at this issue in a single 24-hour period. CISA does not publish the full evidence behind every KEV add. The practical takeaway for a personal site is unchanged: get off the vulnerable core, then look for signs someone already used an upgrade window against you.

What the bug is (without the jargon pile)

WordPress’s own 7.1.4 security release notes describe “a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window,” reported by Umut Bayram. In everyday terms:

1. You (or auto-update) start a full core upgrade.
2. For a short window, update files land under a predictable path that the web server can serve.
3. An attacker who hits that path at the right moment can run their own code.

It is not “every visitor can own every WordPress site at any second.” It is a race during an upgrade. Sites that never use the built-in full-package updater (for example locked-down installs that only deploy from git or a host image) have a different risk shape, but they still need the fixed code. Sites that leave wp-content/upgrade/ reachable on the public web during updates are in the danger zone WordPress and CISA are talking about.

WordPress shipped the fix in 7.1.4 on October 28, 2026, and said security fixes were being backported to older branches that still receive security updates.

Confirm you are on a fixed build

For most personal sites on the current line:

1. Backup files and the database if your host does not already snapshot before updates.
2. If you can, ask your host (or your own nginx / Apache config) to deny web access to /wp-content/upgrade/ before you click Update. Wordfence’s upgrade-window write-up notes that moving from an unpatched core to 7.1.4 still runs the old upgrade path once, so a deny rule narrows that last window. Put the rule in the web server, not only in a PHP plugin, because a staged copy of WordPress may not load your plugins for those requests. Do not postpone 7.1.4 while you wait on the rule. WordPress still says to update immediately.
3. Open Dashboard > Updates.
4. Install WordPress 7.1.4 (or confirm you are already on it).
5. After the success screen, refresh Dashboard > Updates / At a Glance and read the version. You want 7.1.4.
6. If the panel cannot update, download 7.1.4 from WordPress.org or use your host’s documented manual / WP-CLI path.
7. If you are on an older branch that still gets security backports, install that branch’s fixed release instead of pretending 7.1.4 is optional forever. WordPress’s 7.1.4 HelpHub page lists backport builds such as 7.0.8, 6.9.11, and older branch fixes back to 4.7.39. Only the newest WordPress version is actively supported day to day.

Automatic background updates may already have applied 7.1.4. Still log in and read the version yourself. “I think auto-update ran” is not a verification step. Keep the /wp-content/upgrade/ deny rule in place for later full-package upgrades too.

After you patch: a short look-back

Patching closes the hole for the next upgrade. It does not by itself prove nobody won the race during an earlier update. For a personal site, a light check is enough:

1. Look at host or web-server access logs around the times a core update actually ran for requests under wp-content/upgrade/, especially successful hits on staged setup-config.php. Wordfence says the probes it saw asked for that staged installer while attackers tried to catch the upgrade window. A request when no update is running usually 404s, because the staged tree is already gone. The hits that matter are the ones that landed while Dashboard > Updates (or auto-update) was unpacking.
2. Review Users for admin accounts you did not create.
3. Review Plugins and Themes for anything you did not install.
4. If something looks wrong, take the site offline, restore from a clean backup, rotate passwords and host panel credentials from a clean device, then bring a patched copy back.

You do not need a federal incident team for a recipe blog. You do need curiosity for ten minutes before you declare victory.

Do this / don’t do that

Do

• Confirm 7.1.4 (or the fixed backport for your branch) on every personal WordPress you still care about.
• Verify the version after auto-update claims success.
• Skim users, plugins, and upgrade-path logs if the site stayed on 7.1.3 or older through early November.
• Keep unused themes and plugins deleted.

Don’t

• Do not skip the update because “it is only a hobby site.”
• Do not wait for WordPress 7.2 (planned for December 8, 2026 per the 7.1.4 notes) to pick up this fix.
• Do not confuse this KEV item with the earlier wp2shell / CVE-2026-63030 story. Different bug, same habit: patch and verify.
• Do not hunt exploit writeups instead of clicking Update Now.

Bottom line

On November 3, 2026, CISA added WordPress Core CVE-2026-119977 to KEV because of active exploitation of an upgrade-window race that WordPress fixed in 7.1.4 on October 28. On your own site: install 7.1.4 (or the matching backport), confirm the version, then spend a few minutes checking for surprise admins, plugins, and odd wp-content/upgrade/ hits. Our 7.1.4 how-to still has the click-by-click update path. CISA’s listing is the reason not to postpone it.

Image: Official WordPress homepage social image from wordpress.org.