WordPress CVE-2026-119977: Core Upgrade Flaw Added to CISA KEV

CISA added WordPress CVE-2026-119977, a CVSS 8.1 race condition in WordPress Core, to its Known Exploited Vulnerabilities catalog on 4 November 2026, citing active exploitation. No login is needed. The danger sits in the few moments a site spends unpacking a full-package core upgrade, which turns a routine maintenance task into the riskiest thing a site does.

What did CISA add to KEV on 4 November 2026?

CISA listed CVE-2026-119977 in its Known Exploited Vulnerabilities (KEV) catalog on 4 November 2026, stating it has evidence the flaw is being used in attacks. The agency describes a time-of-check time-of-use (TOCTOU) race condition in WordPress Core that “could allow unauthenticated attackers to execute code on the server during the upgrade window.”

The score is 8.1, rated high. No CVSS vector has been published, so the reasoning behind that number is not public; the timing requirement probably keeps it below critical. Do not read 8.1 as a reason to wait. The outcome is a stranger running code on your web server.

U.S. Federal Civilian Executive Branch agencies have until 6 November 2026 to patch. That is two days. Most KEV entries give agencies weeks, not days, so a 48-hour clock tells you how CISA rates the pace of exploitation. No threat actor, campaign or motive has been named.

How does the WordPress core upgrade race condition work?

The bug lives in the upgrade process itself, not in a plugin or an admin screen. During a full-package core upgrade, WordPress downloads the new release, unpacks it into a staging location and then moves the files into place. CISA attributes the flaw to “predictable, web-accessible staging paths used during full-package core upgrades.”

Two conditions combine. The staging location is guessable, and the web server will serve whatever sits there. Between the moment the updater checks the files and the moment it uses them, there is a gap. An outside party who requests the right path inside that gap can reach code the site never meant to expose. This is the textbook TOCTOU pattern (CWE-367).

The scanning traffic revealed the target: staged copies of setup-config.php, the WordPress installation wizard that writes database settings. An already configured site should never have a reachable installer. Wordfence’s point that exploitation “does not require an account on the site” matters here: disabling registration, enforcing admin MFA or hiding the login page does nothing against this path.

Nobody has published the window’s length in seconds. A short window makes reliable exploitation harder. It does not stop an attacker who sprays requests at thousands of sites and waits for one of them to start upgrading.

How much scanning is already hitting WordPress sites?

Scanning began before CISA acted. Wordfence published details of the flaw about a week before the KEV entry, and in the first 21 hours after disclosure it logged more than 18,500 requests aimed at staged installer paths.

The volume has not dropped. As of 4 November, Wordfence reported blocking 12,632 exploitation attempts in the previous 24 hours. Previdian’s honeypot sensors separately recorded three attempts on 30 October 2026 from a single IP address geolocated in the United Kingdom. A UK-geolocated IP tells you nothing reliable about who was actually behind it.

Attackers do not need to find you specifically. They just need you to start an upgrade while their scanner is watching your site. No IP lists, hashes or campaign names have been published, so a blocklist will not protect you. A current patch level and a controlled upgrade procedure will.

Who is exposed in Cyprus and the EU?

Any site running WordPress Core older than the late-October 2026 patch is exposed, and the risk peaks whenever that site runs a full-package upgrade while reachable from the internet. The reporting so far names neither the fixed version nor the affected range, so confirm your version against WordPress.org directly.

For our clients, WordPress is rarely the main product, which is exactly why it gets forgotten. Typical cases:

• Marketing and investor-relations sites for EMIs, brokers and CASPs, often hosted by an outside agency.
• iGaming affiliate and promotional landing pages, built per campaign and never decommissioned.
• Shipping and logistics sites with tracking or careers portals bolted on.
• Staging and pre-production copies that mirror the live site, sit on a public subdomain and upgrade on their own schedule.

WordPress has applied minor and security releases automatically since version 3.7, but auto-updates do not close this hole. The window opens whether a person or a scheduled job starts the upgrade, and major upgrades use the full-package path. “We have auto-updates on” does not mean “we are not exposed.”

How do you upgrade WordPress core safely this week?

Apply the late-October core patch, but do it in a way that closes the window instead of opening it in public:

1. Inventory first. List every WordPress install you own or that an agency runs for you, including staging subdomains. The sites nobody remembers are the ones that get hit.
2. Back up and record a file listing before you touch anything, so you have a clean reference if something looks wrong later.
3. Restrict access during the upgrade. Block public traffic at the reverse proxy or WAF, or allow only your own IPs, for the minutes the upgrade runs. A WordPress maintenance page does not help, because the web server serves staging files directly.
4. Block the staging directory. WordPress unpacks upgrade packages under /wp-content/upgrade/ by default. Deny public HTTP access to it; nothing there ever needs to reach a visitor.
5. Avoid web-triggered unpacking where you can. If you control the server, deploy a pre-built release from your pipeline instead of letting the site unpack its own package on a public host.
6. Confirm the version against WordPress.org’s security release notes. We are not quoting a version number because the reporting has not confirmed one.
7. Never leave an upgrade half-finished. A failed upgrade that leaves files in the staging folder keeps the exposure open long after anyone stops watching.

If an agency manages your sites, ask in writing when they upgraded, which version now runs and whether the staging directory is blocked. That paper trail is what an auditor will ask to see. Our WordPress and CMS penetration testing checks that installer and staging paths are unreachable, alongside core, plugins and configuration.

What are the signs a WordPress site was compromised during an upgrade?

A site that was internet-facing, on pre-patch core and ran a full-package upgrade after the late-October disclosure needs a compromise review, not just an update. Successful exploitation gives code execution as the web server user, so look for what attackers typically do next:

• Requests to /wp-content/upgrade/ or any setup-config.php path outside your own upgrade windows, especially any that returned HTTP 200.
• Core files that do not match the official release. WP-CLI’s wp core verify-checksums compares every core file against WordPress.org’s published checksums and flags anything modified or added.
• New PHP files in wp-content/uploads/, where executable code has no business being.
• Administrator accounts nobody recognizes, and unexpected changes to wp-config.php or .htaccess.
• Outbound connections from the web server to hosts it has never contacted before.

Practitioner’s note: on WordPress engagements, missing logs are the forensic gap we hit most often. Shared and agency hosting often keeps access logs for only a few days, so an upgrade on 30 October may already have rotated out. Pull and preserve logs today.

If the checksum check flags files, do not simply reinstall core: a webshell in uploads or a rogue admin account survives a core reinstall. Rebuild from a known-good backup, rotate database passwords, authentication salts and every API key in wp-config.php, then add file-integrity monitoring so the next upgrade is watched.

If the web server shares credentials or network access with anything else, an assumed breach assessment shows how far an attacker could move from that foothold.

Does a US federal deadline matter to NIS2 or DORA firms?

The 6 November deadline binds only U.S. federal civilian agencies, but the KEV listing still changes your position. A known-exploited flaw on a public site is hard to defend as an accepted risk under NIS2’s risk-management duties or DORA’s ICT risk framework.

If a compromise surfaces, the reporting clocks start. NIS2 entities owe an early warning within 24 hours of becoming aware of a significant incident and a fuller notification within 72 hours. Financial entities under DORA have their own ICT incident reporting, and an agency-run website counts as third-party ICT risk you are expected to oversee.

We saw the same dynamic with CISA’s earlier confirmation of exploited PHP bugs: the KEV date is the date a regulator will assume you knew. If your public sites fall within a NIS2 compliance penetration test, make sure staging subdomains and agency-hosted copies are in scope.

What is still unknown about CVE-2026-119977?

Several basics remain unpublished in the coverage so far:

• The fixed WordPress version and the affected version range.
• A WordPress.org advisory reference.
• The CVSS vector string behind the 8.1 score.
• The measured length of the race window.
• Indicators of compromise such as IPs, domains or hashes.
• Any attributed group or motive.

Until WordPress publishes full release details, checking your running version against the official release notes and verifying core checksums are the only reliable tests.

FAQ

Is CVE-2026-119977 a WordPress plugin bug?

No. It is a flaw in WordPress Core's full-package upgrade process, so it affects sites regardless of which plugins they run.

Can an attacker exploit WordPress CVE-2026-119977 without logging in?

Yes. Wordfence says exploitation does not require an account on the site, so login hardening and disabled registration offer no protection.

Which WordPress version fixes CVE-2026-119977?

Patches were released in late October 2026, but the reporting does not name the fixed version. Confirm it against WordPress.org's official security release notes.

What is the CISA deadline for this WordPress flaw?

U.S. Federal Civilian Executive Branch agencies must apply the fixes by 6 November 2026, two days after the KEV listing.

Does the KEV listing apply to Cyprus companies?

The deadline does not bind Cyprus firms, but a known-exploited flaw on a public site is hard to justify under NIS2 or DORA risk-management duties.

Should I look for setup-config.php on my server?

Yes. Check access logs for requests to setup-config.php or /wp-content/upgrade/ outside your own upgrade windows, and investigate any installer file that should not be there.

Not sure every WordPress site you own, including agency-run and staging copies, is patched and clean? Our WordPress and CMS penetration testing checks core integrity, upgrade exposure and plugins in one pass.