The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-119977, a time-of-check/time-of-use (TOCTOU) race condition in self-hosted WordPress Core‘s upgrade process, to its Known Exploited Vulnerabilities (KEV) catalog on November 3, 2026, based on evidence of active exploitation. CISA says unauthenticated attackers can use it to execute code on the server during the upgrade window.
The fix is WordPress 7.1.4, released October 28, 2026. Federal civilian agencies had a November 6, 2026 deadline; everyone else should update now.
News reports led by BleepingComputer, SecurityAffairs, SC World, and SOCPrime describe the same vulnerability: a time-of-check/time-of-use (TOCTOU) race condition in WordPress’s own core upgrade process, not in a plugin or theme.
The short answer to “am I at risk?” is this. If you run a self-hosted WordPress site that is not on the latest security release, treat this as an emergency patch, not routine maintenance. WordPress.org’s 7.1.4 release notes list the fix as “a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window” and say the security fixes are being backported to every branch still eligible for them, back to 4.7.
What Happened
Here is the confirmed story, per CISA’s KEV catalog entry and WordPress.org’s release notes, with corroborating reporting from BleepingComputer, SecurityAffairs, SC World, and SOCPrime. All sources were retrieved November 6, 2026.
- The flaw type. CISA’s KEV entry describes a time-of-check/time-of-use (TOCTOU) race condition in WordPress Core (CWE-367).
- The attack. CISA says full-package core upgrades use predictable, web-accessible staging paths. During that upgrade window, an unauthenticated attacker could use them to execute code.
- The fix. WordPress 7.1.4, released October 28, 2026, credits Umut Bayram with reporting the upgrade-process weakness.
- The listing. CISA added the flaw to the KEV catalog on November 3, 2026, citing confirmed active exploitation.
Location is what makes this one unusual. Most WordPress security news concerns plugins and themes, which you can audit, disable, or remove. This flaw is reported to sit in the update mechanism itself, not in any add-on.
Because the issue is described as being in Core rather than a plugin, the usual plugin-based mitigations, disabling or removing plugins, don’t apply here. CISA’s materials don’t specify whether a plugin-free install is exposed; treat every self-hosted site as in scope until you confirm your version against an official source.
What the KEV listing means in practice
CISA adds a vulnerability to the KEV catalog when it has a CVE ID, evidence of exploitation, and clear mitigation guidance. Under Binding Operational Directive (BOD 26-04), the KEV entry sets November 6, 2026 as the due date for Federal Civilian Executive Branch (FCEB) agencies. It also marks forensic triage as required, so agencies must check for compromise, not just patch.
BOD 26-04, like other CISA binding directives, legally applies only to FCEB agencies; it does not compel private organizations, or state, local, tribal, and territorial entities, to meet the same deadline. CISA nonetheless encourages everyone else, agencies and private organizations alike, to treat the KEV listing as a strong patch-priority signal regardless of legal mandate.
For a homelab operator or an agency managing client sites, a KEV listing is about as strong a “patch this first” signal as you will get.
CISA’s public KEV catalog page. This is a general view of how the catalog is presented; the screenshot itself does not display the CVE-2026-119977 entry, though CISA’s catalog data lists it as added November 3, 2026.
What’s confirmed, and what still needs verification
CISA’s KEV catalog entry confirms the core facts: the vulnerability is CVE-2026-119977, a WordPress Core TOCTOU race condition in the upgrade process, added to the catalog on November 3, 2026 because of active exploitation, with a November 6, 2026 due date for FCEB agencies under BOD 26-04.
For contrast, we also retrieved CISA’s September 25, 2026 alert, which is a separate, earlier alert covering a different vulnerability:
- CVE: CVE-2026-87902
- Type: WordPress Core Remote File Inclusion
- Added to KEV: September 25, 2026
Don’t confuse the two alerts. They carry different CVEs, different flaw types, and different dates, even though both concern WordPress Core.
An example of CISA’s alert format for a different, earlier WordPress KEV addition (CVE-2026-87902, September 25, 2026). CVE-2026-119977 was added on November 3, 2026, per CISA’s KEV catalog data.
Is Your Site at Risk From the WordPress Remote Code Execution Vulnerability CISA Flagged?
Who this affects
- Affected: Self-hosted WordPress Core installs. That covers anything you or your host run from the open-source package at wordpress.org, whether a VPS, a shared host, or a Docker container on a homelab box.
- Not covered here: Sites hosted on WordPress.com, which is a separately managed hosting service distinct from the self-hosted WordPress.org software this flaw affects. We found no CISA or WordPress.org material addressing WordPress.com’s exposure specifically.
- Plugin status is likely irrelevant here. Because the flaw reportedly sits in Core’s upgrade path rather than in any plugin, removing or disabling plugins would not be expected to prevent exposure, though CISA’s materials don’t explicitly confirm this for plugin-free installs.
- When the exposure exists: CISA ties the risk to the upgrade window, when full-package core upgrades use predictable, web-accessible staging paths, not to normal day-to-day operation.
That narrows the attack surface, but it doesn’t mean you’re automatically safe just because no update is running right now. If your site was running an affected version and an update occurred during the vulnerable window before you patched, treat that as a possible compromise window rather than a clean bill of health.
In that case, review server logs and file integrity for webshells or unexpected files dropped during the update, in addition to confirming you’re now on the fixed version. CISA’s KEV entry for this flaw marks forensic triage as required under BOD 26-04, which reflects the same priority: check for compromise, not just the version number.
Confirmed details, and what still needs verification
| Claim | Value | Source | Verification status (Nov 6, 2026) |
|---|---|---|---|
| CVE identifier | CVE-2026-119977 | CISA KEV catalog entry (added Nov 3, 2026); corroborated by SOCPrime and Aviatrix | Confirmed by CISA |
| Vulnerability type | TOCTOU race condition in WordPress Core’s upgrade process | CISA KEV entry | Confirmed by CISA |
| Affected versions | WordPress 4.7.0 through 7.1.3 | Wordfence advisory linked from CISA’s KEV entry | Reported by Wordfence; WordPress.org says fixes are backported to branches back to 4.7 |
| Fixed version | WordPress 7.1.4 (released Oct 28, 2026) | WordPress.org release notes | Confirmed |
| KEV addition date | November 3, 2026 | CISA KEV entry | Confirmed |
| FCEB remediation deadline | November 6, 2026 | CISA KEV entry, citing BOD 26-04 | Confirmed; applies only to Federal Civilian Executive Branch agencies, not private organizations |
| Probe/attack volume | Elevated scanning and blocked exploit attempts, without a consistent confirmed count | SC World, CISOVoice | Unconfirmed. No CISA telemetry published; reports describe attempts, not breaches |
A note on that last row. A blocked request is a scan or exploit attempt that a web application firewall stopped, not a compromised site. Secondary reports describe active scanning for the staging paths, but even CISA’s confirmation of exploitation doesn’t equate to a published compromise count.
Take the scanning seriously, but don’t repeat any specific attempt count as a breach total. The distinction between attempts and confirmed compromises matters when you’re writing up this incident for a client or manager.
What to do next
One step matters more than any other. Confirm the fixed version from an official source, then get every self-hosted install onto it.
- Open CISA’s KEV catalog and search for WordPress. Confirm the entry matches CVE-2026-119977, added November 3, 2026, with a November 6, 2026 due date for FCEB agencies.
- Target WordPress 7.1.4. If a site must stay on an older branch, use that branch’s latest security release; WordPress.org says the fixes are being backported to every branch back to 4.7.
- Check what each site runs. In the admin, Dashboard > Updates shows the installed version. If WP-CLI is installed, run
wp core version --path=/path/to/wordpressas a user that can read the site files. It prints only the version number, such as7.1.4. - Apply the security release. Sites with automatic background updates enabled may already have it, but confirm rather than assume.
- If the site ran an affected version while an update occurred before you patched, review logs and files for webshells or other compromise indicators, not just the version number.
If you manage a fleet, take a backup before you push updates, for example to an offsite backup drive or a NAS. Keep it separate from older backups: a backup taken after a compromise can contain the attacker’s files, so never treat it as clean or restore it blindly. If you find compromise indicators, restore from a backup that predates the exposure, then patch.
If a WAF such as Wordfence or your host’s firewall sits in front of your sites, check whether the vendor has published a rule for this flaw. Do not treat a WAF rule as a substitute for the Core update.
How It Stacks Up
The closest sourced comparison is WordPress’s own recent history. This is the second WordPress Core flaw CISA has added to KEV since late September: CVE-2026-87902, a remote file inclusion bug, was added September 25, 2026 with a September 28 due date. Two Core entries in about six weeks is a reason to tighten update cadence, not proof the platform is unusually unsafe.
No retrieved source compares this incident with platforms such as Google Workspace, VMware, or Podman, and they aren’t like-for-like substitutes. Running WordPress in a container doesn’t change the Core upgrade code.
On cost, WordPress Core is free, open-source software, but total cost still depends on hosting, support, managed-update services, and staff time. The real cost of this incident is operator time: checking versions, patching, and reviewing sites. No source quantifies that. What we can say is that self-hosting puts the patching burden on you, not on a vendor.
That trade-off has always come with running your own WordPress, managed WordPress hosting included only partly. If your update cadence regularly slips by weeks, the case for a host that patches for you gets stronger. That is a judgment about process, not something this incident’s data proves.
The Reaction
Public reaction is still forming. Our search turned up no Hacker News threads on this story, no Reddit discussion was gathered, and we have no specific posts we can cite. We’ll update this section if substantive discussion emerges.
Our Take
Verdict: Patch now. Hold on any migration decision.
- Patching: adopt immediately. A Core flaw on the KEV list with active exploitation justifies an out-of-band update to 7.1.4, or your branch’s backported security release, for every self-hosted WordPress site you’re responsible for.
- Migrating off WordPress: hold. Nothing in the evidence supports leaving the platform over this. A patched Core bug is a normal part of running any widely deployed software. No source offers comparison data that would make another platform a clearly safer or cheaper choice.
- Cost to an IT shop: The license cost is unchanged, since Core is free. The added expense is staff time to verify, patch, and spot-check. That cost grows with fleet size and with how much of your update process is manual. Shops that already automate WordPress updates and keep version inventories will absorb this in an afternoon. Shops that don’t will feel it, and should fix the update process as well as this one bug.
There is an uncomfortable irony here. CISA says the exposure exists during the upgrade window, and the fix requires running an update. That argues for patching quickly and deliberately, and then checking logs for compromise indicators if any site was exposed during that window, rather than leaving sites in a half-updated state. It does not argue for skipping the update.
Wrapping Up
If you run self-hosted WordPress, treat this as a real emergency. CISA lists CVE-2026-119977 as actively exploited, and WordPress 7.1.4 has been available since October 28, 2026. Patch everything, then check any site that may have been exposed during an earlier update.
My view: this is a patch-and-move-on event, not a platform crisis. The lasting lesson is about process. If you can’t answer “what WordPress version is every site on?” within five minutes, start building that inventory this week.
| Step | Action | Applies To |
|---|---|---|
| 1 | Look up the WordPress entry in CISA’s KEV catalog; confirm CVE-2026-119977, the November 3, 2026 addition date, and the November 6, 2026 FCEB due date | Everyone managing self-hosted WordPress |
| 2 | Target WordPress 7.1.4, or the latest security release on your branch | Everyone managing self-hosted WordPress |
| 3 | Check installed versions (Dashboard > Updates or wp core version) | Each self-hosted site |
| 4 | Back up, then apply the official security release | Any site below the fixed version |
| 5 | Treat attack-attempt counts as threat signals, not breach counts | Anyone reporting on this to clients or management |
| 6 | If an update ran during the vulnerable window before patching, review logs and files for compromise indicators | Any site that may have been exposed |