The short answer

WordPress 7.1.4, released on October 28, 2026, patches CVE-2026-119977, a race condition in the WordPress upgrade process. On affected sites, an unauthenticated attacker who hits a predictable staging path during the short window of a full core update can run code on the server. CISA added the flaw to its Known Exploited Vulnerabilities catalog on November 3, 2026, based on evidence of active exploitation, and lists a federal due date of November 6, 2026. If your site is not on WordPress 7.1.4 or the matching security release for your branch, update as soon as you can do so safely, and confirm that the update actually completed.

What CVE-2026-119977 is

CISA describes CVE-2026-119977 as a time-of-check time-of-use (TOCTOU) race condition in WordPress Core. In plain language: the dangerous moment is not everyday browsing. It is the moment WordPress is applying a full-package core upgrade.

WordPress.org's 7.1.4 announcement called it "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window," reported by Umut Bayram. NHS England, citing the same issue, says WordPress Core versions 4.7 through 7.1.3 are vulnerable because they use predictable, web-accessible staging paths during those upgrades. An attacker does not need an account on the site.

Patchstack's write-up of the release explains the practical limits. The attacker has to catch the seconds-long window while an update is running, and wp-content/upgrade/ has to be reachable over the web. That is why the issue is treated as high complexity. NHS England lists a CVSS v3.1 score of 8.1. The window is brief, but it returns every time a full core update runs, including unattended automatic updates.

7.1.4 was not only this one fix. WordPress.org listed additional issues in the same release, including several stored cross-site scripting flaws, a stored denial-of-service issue in the Interactivity API, unpublished Customizer changesets that unauthenticated visitors could discover, and a notes-permissions issue. Patchstack counted what WordPress treated as 22 vulnerabilities across 17 advisories. The upgrade-window race condition is the one that needs no login, and it is the one CISA later flagged as exploited.

Who needs to act

You should treat the site as in scope if it runs WordPress 7.1.3 or earlier, including older 7.0, 6.x, and 5.x installs back through 4.7. NHS England states the affected range as versions 4.7 to 7.1.3. The current official release from WordPress.org, confirmed by the project's version-check API on November 5, 2026, is 7.1.4. WordPress also shipped backport updates for older branches. Patchstack reported those backports going out the same day, down to 4.7.39. The version-check API currently offers patched releases such as 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, and 6.5.14 as automatic updates for sites still on those branches.

WordPress.org is explicit that only the most recent version is actively supported. If you are still on an older branch, apply the latest security release available for that branch now, then plan a move to a currently supported release rather than staying behind indefinitely.

Why this was in the news again this week

The patch landed on October 28. The reason it is trending again in the first week of November is CISA. On November 3, 2026, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog, stating it had evidence of active exploitation. The catalog entry itself lists a due date of November 6, 2026 for federal agencies acting under Binding Operational Directive 26-04.

Binding Operational Directive 26-04 tells U.S. Federal Civilian Executive Branch agencies to treat KEV items as a priority. BleepingComputer reported on November 4 that those agencies were told to secure their systems by Friday, November 6, 2026. CISA also encouraged organizations outside the federal government to prioritize the same class of flaws. NHS England's alert, updated on November 4, says its National CSOC assesses further exploitation as likely.

BleepingComputer, citing a Wordfence advisory update from the previous weekend, reported that Wordfence blocked 13,095 attacks targeting this vulnerability in the prior 24 hours. Other publishers have quoted different totals. We are citing the BleepingComputer figure because we opened that article. Attack counts move quickly and are not something we invent or round up.

What to do now

  1. Check the running version. In wp-admin, go to Dashboard, then Updates. You want to see WordPress 7.1.4, or the matching patched release if you are still on an older branch.
  2. Do not assume automatic updates finished. WordPress.org says eligible sites should start updating in the background. Confirm the new version anyway. A failed or stuck update can leave a site looking unchanged.
  3. Update now if you can do it safely. Use Dashboard > Updates > Update Now, or download the release from WordPress.org. Take a backup first if you do not already have a recent, restorable one.
  4. If the site is fragile, get help before clicking Update. Aging plugin stacks, abandoned themes, and custom code are why many owners delay security releases. Delaying leaves the upgrade window in place for the next full core update. A careful backup, update, and smoke-test of login, forms, and checkout is the safer path. See our pages on WordPress Updates and WordPress Rescue.
  5. Stay on a supported line afterward. WordPress.org's next major release, version 7.2, is currently planned for December 8, 2026. Security backports exist, but they are not a substitute for running a maintained version.

Why this lands hardest on aging WordPress sites

The owners we talk to about WordPress Rescue are often not ignoring security on purpose. They delayed an update because a previous one white-screened the site, because no one on the team owns the plugins, or because the last developer left without documentation. Automatic updates may have been turned off after a failure, or they may still be on but silently failing.

CVE-2026-119977 makes that holding pattern more expensive. The vulnerability is in the upgrade process itself. You still need to apply 7.1.4 (or the backport for your branch) to remove it. On a healthy site that is a short task. On a neglected site it is the kind of work that should happen after a backup and a quick review of what might break, not after a scare and a rushed click.

That is the work we do first: review hosting, WordPress core, themes, plugins, access, and backups, then stabilize the live site. If the stack is sound enough to keep, we apply the security release and watch the critical paths. If the site is too brittle to keep patching, we can still protect it in the short term and then write a scope for replacement while the current site stays online.

This is also not the same problem as PHP2Shell, which is a PHP runtime issue patched on October 21, 2026, or CVE-2026-111497 in Brotli, which is a server library issue. A neglected host can need more than one of these updates.

How NTx can help

If you are not sure which version you are on, cannot get into wp-admin, or do not want to run this update without a safety net, start with a conversation about WordPress Security or a Rescue assessment. We will tell you what we see and agree on next steps before any rebuild conversation. WordPress is not automatically "the problem." Sometimes the right move is a careful update and a care plan. Sometimes it is a planned replacement. Either way, the current security release should not wait on a redesign.

FAQ

What is CVE-2026-119977?

CVE-2026-119977 is a time-of-check time-of-use race condition in WordPress Core. During a full-package core upgrade, affected versions unpack files into a predictable, often web-accessible staging path. An unauthenticated attacker who reaches that path while the update is still running can execute code on the server. WordPress 7.1.4 patches the issue.

Which WordPress versions are affected?

NHS England states that WordPress Core versions 4.7 through 7.1.3 are affected. WordPress 7.1.4 is the current patched release. WordPress also backported the security fixes to older eligible branches, down to 4.7.39 according to Patchstack. WordPress.org notes that only the most recent version is actively supported.

How do I check whether my site is patched?

In wp-admin, open Dashboard, then Updates, and confirm the reported WordPress version is 7.1.4 or the matching security release for your branch (for example 7.0.8 or 6.9.11). Do not assume an automatic background update finished. If you cannot log in, ask your host or a developer to check the version on disk.

If automatic updates are on, am I already safe?

Not necessarily. WordPress.org says sites that support automatic background updates should begin updating on their own, but NHS England and WordPress both encourage you to confirm that the update completed. Automatic updates can fail on sites with file-permission problems, exhausted disk space, or a stuck update lock.

Is this the same issue as PHP2Shell?

No. PHP2Shell refers to two critical flaws in the PHP language itself (CVE-2026-109618 and CVE-2026-109619), fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. CVE-2026-119977 is a WordPress Core upgrade-process race condition patched in WordPress 7.1.4 on October 28, 2026. A site can need both a PHP update and a WordPress update.

What if I am afraid an update will break my site?

That concern is common on aging WordPress sites with abandoned plugins, custom code, or no recent backups. The security release still needs to be applied. Take a backup first, or ask someone who can stabilize the site, apply the update, and check forms, login, and checkout afterward. NTx Ventures can do that assessment and update work, and can also discuss whether the site should later be replaced rather than patched indefinitely.

Sources

  1. Aaron Jorbin, "WordPress 7.1.4," WordPress News, October 28, 2026. https://wordpress.org/news/2026/10/wordpress-7-1-4/
  2. CISA, "CISA Adds One Known Exploited Vulnerability to Catalog," November 3, 2026. https://www.cisa.gov/news-events/alerts/2026/11/03/cisa-adds-one-known-exploited-vulnerability-catalog
  3. CISA Known Exploited Vulnerabilities catalog entry for CVE-2026-119977, date added November 3, 2026, due date November 6, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  4. Sergiu Gatlan, "CISA flags WordPress RCE flaw as actively exploited in attacks," BleepingComputer, November 4, 2026. https://www.bleepingcomputer.com/news/security/cisa-flags-wordpress-rce-flaw-as-actively-exploited-in-attacks/
  5. NHS England Digital, "WordPress Releases Security Update Addressing Multiple Vulnerabilities" (CC-4884), published October 30, 2026, last edited November 4, 2026. https://digital.nhs.uk/cyber-alerts/2026/cc-4884
  6. Dave Jong, "WordPress 7.1.4 Security Release," Patchstack, October 28, 2026. https://patchstack.com/articles/wordpress-7-1-4-security-release/
  7. WordPress.org news, "WordPress 7.2 Beta 4," November 3, 2026 (7.2 planned for December 8, 2026). https://wordpress.org/news/2026/11/wordpress-7-2-beta-4/
  8. WordPress.org news, "Critical PHP Security Release," October 21, 2026. https://wordpress.org/news/2026/10/critical-php-security-release/