---
title: "WordPress 7.1.4: Unauthenticated Upgrade-Window RCE"
url: https://erroneo.us/security/briefs/wordpress-7-1-4-upgrade-window-rce-cve-2026-119977/
description: "CISA lists the WordPress core upgrade-race RCE (4.7 to 7.1.3) as exploited, with a Nov 6 federal deadline. Confirm 7.1.4 or your branch's backport now."
type: security-brief
section: "Security Digest"
date_published: 2026-10-28
date_modified: 2026-11-04
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Act now"
cves: ["CVE-2026-119977"]
severity: "high"
exploited: "in-the-wild"
kev: true
license: All rights reserved. Quote with attribution and a link.
---

# WordPress 7.1.4: Unauthenticated Upgrade-Window RCE

**Verdict: Act now.** CISA now lists this as exploited and Wordfence is blocking thousands of attempts a day; the window is narrow, but confirm today that every site is on 7.1.4 or its branch backport and block PHP under wp-content/upgrade/.

- **Who must act:** Self-hosted WordPress sites that update core through the built-in updater or WP-CLI, especially those with background updates disabled or still on an old branch.
- **Who can relax:** Sites already on 7.1.4 or a fixed backport, sites on hosts that confirm platform mitigations, and installs deployed by Composer, Git or images that never run the in-app core updater (they still want the other 21 fixes).
- **Affected:** WordPress 4.7.0 through 7.1.3 (per the CVE record; each branch up to the release before its backport); WordPress 4.6 and earlier: no fix, those branches are unsupported
- **Fixed:** WordPress 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, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34, 4.7.39
- **CVEs:** CVE-2026-119977
- **CISA KEV:** yes · **Exploitation:** Exploited in the wild

## What to do

1. 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.
2. Deny execution of PHP under wp-content/upgrade/ at the web server, ideally before running any further core update.
3. Update sites with background updates disabled now: wp core update, then wp core update-db.
4. Move sites on 4.6 or earlier to a supported branch; they receive no fix.
5. 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

- 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](https://wordpress.org/news/2026/10/wordpress-7-1-4/), a security release. The [release notes](https://wordpress.org/support/wordpress-version/version-7-1-4/) 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](https://www.cve.org/CVERecord?id=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](https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/), 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](https://gbhackers.com/wordpress-7-1-4-fixes-22-security-vulnerabilities/) 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](https://www.cisa.gov/news-events/alerts/2026/11/03/cisa-adds-one-known-exploited-vulnerability-catalog) 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](https://www.bleepingcomputer.com/news/security/cisa-flags-wordpress-rce-flaw-as-actively-exploited-in-attacks/) 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

1. 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.
2. 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.
3. Update lagging sites: `wp core update` then `wp core update-db`. For pinned old branches, `wp core update --minor` installs the branch backport.
4. Upgrade any site still on 4.6 or earlier to a supported release.
5. 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.

## Sources

1. [CVE.org — CVE-2026-119977: WordPress Core 4.7.0 - 7.1.3 Unauthenticated Upgrade-Window Staged-Installer RCE](https://www.cve.org/CVERecord?id=CVE-2026-119977)
2. [WordPress.org — WordPress 7.1.4](https://wordpress.org/news/2026/10/wordpress-7-1-4/)
3. [WordPress.org — Version 7.1.4 release notes and backported branches](https://wordpress.org/support/wordpress-version/version-7-1-4/)
4. [CISA — CISA Adds One Known Exploited Vulnerability to Catalog (Nov 3, 2026)](https://www.cisa.gov/news-events/alerts/2026/11/03/cisa-adds-one-known-exploited-vulnerability-catalog)
5. [BleepingComputer — CISA flags WordPress RCE flaw as actively exploited in attacks](https://www.bleepingcomputer.com/news/security/cisa-flags-wordpress-rce-flaw-as-actively-exploited-in-attacks/)
6. [SecurityWeek — Fresh WordPress Vulnerability in Attackers' Crosshairs](https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/)
7. [GBHackers — WordPress 7.1.4 Fixes 22 Security Vulnerabilities](https://gbhackers.com/wordpress-7-1-4-fixes-22-security-vulnerabilities/)

---
Source page: https://erroneo.us/security/briefs/wordpress-7-1-4-upgrade-window-rce-cve-2026-119977/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt