WordPress 7.1.4 upgrade-window RCE is now on CISA's exploited list

CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, 2026. The bug is a race condition in the WordPress core upgrade process that lets an unauthenticated attacker run code on the server while an update is in progress. It affects every branch from 4.7 through 7.1 below its patched release. The fix shipped in WordPress 7.1.4 on October 28, with backports for older branches. If any site you manage is still below the patched release for its branch, update it today.

Software	WordPress core
CVE	CVE-2026-119977
Severity	CVSS 3.1 8.1, High (attack complexity rated high)
Type	Time-of-check time-of-use race condition (CWE-367) leading to remote code execution
Affected versions	Every branch from 4.7 through 7.1 below its patched release (for example 7.1.0 to 7.1.3, 7.0.0 to 7.0.7, 6.9.0 to 6.9.10)
Fixed in	7.1.4; backports 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 and older branches down to 4.7.39
Conditions	No account needed. The request must land during the seconds-long core update window, and wp-content/upgrade/ must be reachable over the web
Exploited	Yes. CISA added it to the KEV catalog on 2026-11-03 and records exploitation as active
Found by	Umut Bayram

Why is the WordPress upgrade folder exploitable?

WordPress unpacks every package it installs into wp-content/upgrade/, which sits inside the web root, so the web server serves whatever is in it. According to Patchstack's analysis of the release, versions before 7.1.4 named the unpacked folder after the package, so the path was easy to guess, and the cleanup step that ran first removed the index.php that normally prevents directory listing.

For the few seconds a core update takes, a complete, browsable copy of WordPress sits at a predictable URL. That copy includes the installer script, which boots without the site's own configuration. An attacker who reaches it in time can point the installer at a database they control and run code inside the site's document root.

The NVD record for CVE-2026-119977 describes the cause as predictable, web-accessible staging paths during full-package core upgrades and classifies it as CWE-367. Wordfence filed the CVE and scored it 8.1 on CVSS 3.1, and rated attack complexity as high.

Patchstack notes the vulnerable code goes back to WordPress 2.8 and that any update, unattended ones included, opens the window again. NVD ties the exposure to full-package core upgrades.

Attackers lose the predictable staging path

The fix in 7.1.4 adds 16 random characters to the name of the extraction folder, recreates index.php inside it and no longer deletes that file during cleanup. Patchstack also found an update-core.php change that the release post leaves out: the updater now excludes wp-config.php when it copies files from the staging directory.

WordPress.org said backports to every branch still eligible for security fixes, currently back to 4.7, were in progress. Patchstack lists them as shipped the same day, and the NVD version ranges match. Sites on 4.6 or earlier receive nothing and need a full upgrade.

The KEV listing confirms real use but not its scale

Patchstack scored the bug with high attack complexity and would not call it practical to exploit, since the attacker has to request the right path while an update is running. CISA's assessment, recorded in the NVD entry on November 3, lists exploitation as active, rates it as not automatable and gives technical impact as total. The catalog entry sets a required-action due date of November 6, 2026 under CISA's BOD 26-04 guidance on prioritizing updates by risk.

None of the sources give attack counts or describe the campaigns, so treat the listing as confirmation of real-world use rather than a measure of scale.

Stock installs with a reachable upgrade folder

• Any site on a branch from 4.7 through 7.1 that is below the patched release for that branch (for example 7.1.3, 7.0.7, 6.9.10 or 6.8.11).
• The attacker needs no account and no interaction from anyone on the site.
• wp-content/upgrade/ must be reachable from the web, which is the default on a stock install.
• The attack only works while a core update is unpacking, including automatic background core updates, so sites that update often open the window more often.

Sites with disabled background updates may still be unpatched

In wp-admin, go to Dashboard, then Updates. Sites with background updates enabled should already show 7.1.4 or the backport for their branch.

With WP-CLI, check and update from the shell:

wp core version
wp core update
wp core verify-checksums

For a fleet, run the check across every install path:

for d in /var/www/*/public; do echo "$d $(wp core version --path=$d)"; done | sort -k2

Do not assume background updates ran; check the version itself. If a site lags, check whether background updates are disabled, or blocked by file permissions or a wp-config.php setting.

Deny rules in nginx or Apache

Patchstack's advice is to block web access to wp-content/upgrade/ at the web server level and confirm the directory is not listable. Between updates it holds only an index.php, so denying requests to it breaks nothing, and the rule is worth keeping after you update.

A PHP-level firewall plugin does not help here. Patchstack explains that the staged copy boots from its own bundled WordPress files, and because the official package has no mu-plugins folder, no firewall code from the live site is loaded for that request. The rule has to live in nginx, Apache or whatever sits in front of PHP.

Leftover files in the upgrade folder can signal an attack

Because the attack runs the installer against an outside database, traces are most likely on disk, so start there. As a checklist, look for:

• Anything other than index.php inside wp-content/upgrade/, especially a full WordPress directory tree left behind.
• A modified or duplicated wp-config.php, or one with a database host you do not recognize.
• Files in the web root that wp core verify-checksums reports as modified or unexpected.
• Administrator accounts, scheduled tasks or plugins you did not create.

If you find any of these on a site that was below 7.1.4, standard incident handling applies: take it offline, restore from a backup taken before the earliest suspicious change, update core to the patched release, then rotate the database password, the salts in wp-config.php and every admin password. Reinstall core from a fresh package rather than cleaning files in place.

Contributor accounts and the Interactivity API

7.1.4 fixes 22 vulnerabilities across 17 advisories by WordPress's count, as reported by Patchstack, up from seven in 7.1.3 three weeks earlier. The upgrade race is the only one that ends in code execution without a login. Most of the rest start with a Contributor account, so Patchstack recommends reviewing who holds Contributor and above on every site.

Seven advisories concern the Interactivity API. They share one root cause. KSES let through data-* attributes with arbitrary values, and Interactivity directives are written as data-* attributes, so a Contributor could store directives in a post that the front-end runtime then executed for visitors. 7.1.4 tightens this in KSES, the PHP directive processor and the runtime. One item is a denial of service that hangs the visitor's browser tab rather than the server.

Unauthenticated visitors could discover unpublished Customizer changesets through a preview request with no changeset ID; 7.1.4 now requires the customize capability. And notes on posts could be read, edited or deleted by roles holding moderate_comments without edit access to the post, which only matters where a custom role, plugin or post type separates those capabilities. The release also refreshes the bundled root certificates after the eMudhra revocation.

CISA gave the catalog entry a November 6 due date

• October 28, 2026: WordPress 7.1.4 released. Patchstack lists backports shipped the same day down to 4.7.39.
• October 31, 2026: NVD publishes CVE-2026-119977, filed by Wordfence.
• November 3, 2026: CISA adds the CVE to the Known Exploited Vulnerabilities catalog with exploitation recorded as active.
• November 6, 2026: CISA's required-action due date for the catalog entry.
• December 8, 2026: planned release of WordPress 7.2; WordPress.org says 7.2 Beta 3 already contains the fixes.

Once every site shows 7.1.4 or its branch backport, add the wp-content/upgrade/ deny rule to your standard server config as an extra layer of protection for future update windows.