WordPress 7.1.4: Unauthenticated Upgrade-Window RCE

What to do

Check the running version on every site (wp core version) and confirm it is 7.1.4 or the fixed release for its branch; do not assume background updates finished.
Deny execution of PHP under wp-content/upgrade/ at the web server, ideally before running any further core update.
Update sites with background updates disabled now: wp core update, then wp core update-db.
Move sites on 4.6 or earlier to a supported branch; they receive no fix.
Review access logs for requests to PHP files under wp-content/upgrade/ since October 28 and investigate any that returned 200.

How to check if you are affected or compromised

grep -E 'wp-content/upgrade/.*\.php' in web server access logs since October 28, 2026; a 200 response deserves investigation.
Run wp core verify-checksums and wp user list --role=administrator, and look for administrator accounts nobody created.
Check wp-config.php for an unexpected modification time or changed database settings, and look for PHP files you did not deploy under wp-content/.
If you use Wordfence, check firewall logs for blocks on the upgrade-path rule added October 28.

What happened#

On October 28, 2026, WordPress shipped 7.1.4, a security release. The release notes list 22 vulnerabilities, most of them stored XSS that needs a Contributor account or higher, and also a refresh of bundled root certificates after the eMudhra CA compromise. One item stands out: "a race condition during core updates that could lead to remote code execution," reported by Umut Bayram.

Wordfence, acting as the CNA, published CVE-2026-119977 on October 31. The record says the cause is "predictable, web-accessible staging paths used during full-package core upgrades," which lets "unauthenticated attackers to execute code on the server during the upgrade window." It scores the flaw CVSS 3.1 8.1 (AV:N/AC:H/PR:N/UI:N) and classes it as CWE-367, a time-of-check/time-of-use race. The record's title names the piece at risk: the staged installer. During a full upgrade, WordPress unpacks a complete copy of itself, including wp-admin/setup-config.php, into a folder under wp-content/upgrade/ before moving files into place.

Per SecurityWeek, which relays Wordfence's report, the fix randomizes the staging directory name, adds an index guard, and stops unsafe promotion of staged configuration data. Wordfence deployed a firewall rule on release day. The first matching request arrived nine minutes later, and it recorded more than 18,500 requests aimed at staged setup-config.php paths in the first 21 hours. GBHackers adds that two sources repeatedly polled small groups of sites for about 14.5 hours. Wordfence has not reported a successful compromise.

Who is affected#

Every WordPress branch from 4.7 to 7.1.3. WordPress backported the fix to all branches back to 4.7, so each has its own fixed release (7.0.8, 6.9.11, 6.8.12 and so on, listed in the verdict panel). Branches 4.6 and earlier get nothing. On November 3, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog, citing evidence of active exploitation, and gave federal civilian agencies until November 6 to remediate under BOD 26-04.

The vulnerable code runs only during a full-package core upgrade performed by WordPress itself, whether started by a background update, the dashboard or wp core update. Our reading of the CVE description is that sites whose core files are deployed by Composer, Git or container images, and which never run the built-in core updater, don't open the window. They should still take 7.1.4 for the other fixes.

Do you really need to act?#

Update, November 4: Yes, more urgently than before. The KEV listing means CISA has evidence of exploitation, not just probing, though it has not published details and no specific compromised site has been reported. Attack volume has not dropped: BleepingComputer relays a Wordfence update from the weekend saying it "blocked 13,095 attacks targeting this vulnerability in the past 24 hours." Every core update you run on an unpatched branch reopens the window, so patch lagging sites and add the server-level block now rather than this week. CISA's federal deadline is three days, and BOD 26-04 also asks agencies to check for compromise from before the patch, which is good advice for everyone.

This is a real unauthenticated RCE in the most widely deployed CMS, but it is hard to hit. The attacker needs the staged files to be reachable and executable over HTTP, needs to know or guess the staging path, and must send the request in a window that Wordfence's lab measured in seconds before WordPress cleans up. That explains the CVSS "AC:H" and the polling pattern: attackers hammer predictable paths, hoping to catch a site mid-upgrade.

The timing of the attacks is the uncomfortable part. Probing started while millions of sites were auto-updating to 7.1.4. The sources don't say whether the upgrade to 7.1.4 itself still uses the old predictable path, since that step is driven partly by the code being replaced. Treat October 28 and 29 as the riskiest window and check logs for it, rather than assuming the patch closed the door before attackers arrived.

Most sites with background updates on have already moved to 7.1.4 or their branch's backport. The sites that need attention are those with automatic updates disabled, managed hosts that hold back core, and fleets nobody has looked at in a while.

What to do now#

Inventory versions: wp core version on each site, or check the Updates screen. Anything below 7.1.4 must be on its branch's fixed release from the list above.
Block PHP execution under wp-content/upgrade/ at the server. On nginx: location ~* ^/wp-content/upgrade/.*\.php$ { deny all; }. On Apache, use a <LocationMatch> or <Directory> block with Require all denied in the vhost, so a WordPress cleanup can't delete it. Do this before you run the next core update.
Update lagging sites: wp core update then wp core update-db. For pinned old branches, wp core update --minor installs the branch backport.
Upgrade any site still on 4.6 or earlier to a supported release.
Treat a web application firewall rule as a stopgap. Patching, plus the server-level block above, is the fix.

How to tell if you were hit#

Search access logs from October 28 onward for requests to PHP files under the staging folder, for example grep -E 'wp-content/upgrade/.*\.php' /var/log/nginx/access.log*. Requests that returned 404 are failed probes. A 200 or a POST that lines up with your update time needs investigation. Then check the site itself: wp core verify-checksums, wp user list --role=administrator for unknown admins, the modification time and database settings in wp-config.php, and any PHP files under wp-content/ that you did not deploy.

Timeline#

Oct 28, 2026 — WordPress 7.1.4 and backports released with 22 fixes. Wordfence deploys a firewall rule, and the first matching exploit attempt arrives nine minutes later.
Oct 29, 2026 — Wordfence counts more than 18,500 requests to staged installer paths in the first 21 hours. The WordPress.org announcement is updated.
Oct 31, 2026 — CVE-2026-119977 published by Wordfence (CVSS 8.1). No confirmed compromises reported and no KEV listing.
Nov 3, 2026 — CISA adds CVE-2026-119977 to KEV, with a federal due date of November 6.
Nov 4, 2026 — BleepingComputer relays a weekend Wordfence update reporting 13,095 blocked attacks in 24 hours. No specific compromise has been made public.

Vulnerability records

CVE-2026-119977 · KEV 2026-11-03 · WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

Coverage and analysis

BleepingComputer — CISA flags WordPress RCE flaw as actively exploited in attacks bleepingcomputer.com
SecurityWeek — Fresh WordPress Vulnerability in Attackers' Crosshairs securityweek.com
GBHackers — WordPress 7.1.4 Fixes 22 Security Vulnerabilities gbhackers.com