WordPress 7.1.4: Unauth Upgrade-Window RCE Is Being Probed - Floor 7.1.4

WordPress 7.1.4 is a security release shipped 28 October 2026, 17:13 UTC. WordPress lists 22 issues. The one that matters on a shared host is a weakness in the Core upgrade process that can lead to remote code execution during the upgrade window, reported by Umut Bayram. HelpHub calls it a race condition during core updates. As of this writing WordPress has not published a CVE ID. Wordfence scores the RCE CVSS 8.1 High. That 8.1 is Wordfence's, not WordPress.org's.[1][2][3]

Wordfence telemetry, published 29 October: first firewall-rule match nine minutes after they deployed the rule (20:30 UTC 28 October). More than 18,500 requests at staged setup-config.php installer paths in the first 21 hours. Two large sources polled small groups of sites for about 14.5 hours. Wordfence has not reported a successful compromise.[3][4]

If you run WordPress on cPanel, Plesk, or a VPS, this is the version floor and what to look at after you update.

What it is

During a full-package Core update, affected versions unpack the new tree into a predictable directory under wp-content/upgrade/. That copy includes the WordPress installer. On many servers that directory is web-accessible and will run PHP. An unauthenticated attacker who requests the staged installer at the right moment can interact with that copy and progress to PHP code execution. Wordfence's conditions: a full-package update that contains the installer, public web and PHP access to the staging tree, a predictable or discovered path, and enough time before Core cleans up.[3]

WordPress 7.1.4 changes three things Wordfence names (HelpHub lists the same two files: class-wp-upgrader.php and update-core.php):[2][3]

Randomize the staging directory name
Index guard in the upgrade folder
Do not promote staged configuration data out of the working directory

We did not reverse the upgrader. The public facts stop at: predictable, web-reachable staging path during a full Core unpack, unauthenticated, RCE if the race is won.

The currently installed Core is what unpacks the new package. The 7.1.4 zip is delivered by 7.1.3's (or older) upgrader. That is how WordPress updates work, not a second bug. Block wp-content/upgrade/ at the web server before you click Update if you can.

How serious

Wordfence 8.1 High. They put the eventual impact at code execution on the server and the attack complexity at high. In their lab the staging directory was only there for seconds. A single opportunistic GET is unlikely. Repeated polling is what they are seeing.[3]

WordPress.org did not score CVSS and did not say "actively exploited." The exploitation claim is Wordfence telemetry of attempt traffic, plus SecurityWeek's 30 October write-up of that same post. Attempts are not the same as a confirmed takeover. Wordfence said they have not reported successful compromises.[3][4]

This is not on CISA KEV as of the catalog we used for yesterday's GitLab KEV post. Do not invent a KEV row.

The rest of 7.1.4 is mostly Contributor+/Author+/Editor+ stored XSS, Interactivity API issues, an unauthenticated Customizer changeset disclosure, a Notes REST authorization miss, and the eMudhra root-store update. Those are real; they are not this RCE.[1][2]

Who is affected

Wordfence: WordPress Core 4.7 through 7.1.3. Patched versions they list:[3]

4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11, 7.0.8, 7.1.4

HelpHub's branch notes (not every branch got all 22 issues):[2]

7.1 → 7.1.4 (all 22)
7.0 → 7.0.8 (all 22)
6.9 → 6.9.11 (all 22)
6.8 → 6.8.12 (20 of 22)
6.7 → 6.7.11 (20 of 22)
6.6 → 6.6.11 (19 of 22)
6.5 → 6.5.14 / 6.4 → 6.4.14 (17 of 22)
6.3-6.0 / 5.9 → the 6.3.14 … 5.9.20 line (9 of 22)
5.8-5.0 → the 5.8.19 … 5.0.31 line (6 of 22)
4.9 → 4.9.35 (4 of 22)
4.8 → 4.8.34 / 4.7 → 4.7.39 (2 of 22)
4.6 and earlier: WordPress no longer ships security updates. Migrate.

A PHP firewall plugin does not load for a request that hits the staged installer directly. Wordfence says Extended Protection is required for their rule to see it, and the rule is not a substitute for the Core update. Free Wordfence users get that rule on 27 November 2026 (30-day delay).[3]

What to do now

Read the running version, not the last email from the panel.

wp core version --allow-root
# or
grep wp_version wp-includes/version.php

You want 7.1.4, or the patched release for that branch from the list above.

Deny the upgrade tree at nginx/Apache before you update, so the last unpack of the old upgrader is not a public installer. Put this in the vhost, not in a file inside wp-content/upgrade/ (the old cleanup empties that folder).

location ^~ /wp-content/upgrade/ {
    deny all;
}

RedirectMatch 403 ^/wp-content/upgrade/

Update Core. Auto-updates can fail silently. Do it from Dashboard → Updates, or:

wp core update --allow-root
wp core version --allow-root
wp core verify-checksums --allow-root

On a host with many accounts, loop wp per docroot. Do not skip verify-checksums.

If you cannot update today, keep the deny rule, turn off directory listing on wp-content/, and do not leave PHP execution in wp-content/upgrade/. Isolation (maintenance page / IP allowlist) is the stopgap. There is no WordPress.org "disable updates to stay safe" switch that we will invent - skipping updates leaves the next auto-update as the window.
Hunt if the site was unpatched through 28-31 October. Patching does not unwind a win during an earlier unpack.

find wp-content/upgrade -type f -name '*.php' ! -name 'index.php' -ls
stat wp-config.php
grep -E 'DB_HOST|DB_NAME|DB_USER' wp-config.php

In access logs, look for wp-content/upgrade plus setup-config.php or install.php. Legitimate traffic has no reason to request those. Wordfence's named target is staged setup-config.php installer paths.[3]

Versions with no clean vendor patch

4.6 and earlier are out of WordPress security support. There is no 4.6.x floor for this. Rebuild on a supported branch or take the site off the internet.[2]

Managed WordPress / panel "auto-update" products: confirm the running version, not the marketing page. If the vendor pins an old minor, open a ticket with the HelpHub floor for that line.

How to spot a compromise

WordPress and Wordfence did not publish IoCs beyond the request path. We are not inventing hashes.

Look for: PHP files under wp-content/upgrade/ other than index.php; a wp-config.php whose DB_HOST / DB_NAME you do not recognize; new administrator users; plugins you did not install; outbound curl/wget from the PHP user around an update timestamp.

Isolate first. Keep logs. We are not publishing exploit steps.

FAQ

Is there a CVE? Not in the WordPress 7.1.4 notes, not in HelpHub, and SecurityWeek (30 Oct) still said none assigned. Track the release, not a CVE string we made up.[1][4]

Is this unauthenticated RCE? Wordfence: yes, if the attacker hits the unpack window on a full-package update with a web-reachable staging tree. WordPress: RCE during the upgrade window. Keep both hedges.[1][3]

Do automatic updates save me? They are how most sites get 7.1.4. They are also the window on an unpatched unpacker. Check the version. Do not assume.

Does a Wordfence / Patchstack plugin replace 7.1.4? No. Wordfence said so. The request never boots the live site.[3]

Is this PHP2Shell? No. PHP2Shell is CVE-2026-109618 / 109619 in the PHP engine. This is Core's upgrader. Patch both.

Honesty

We did not exploit this. No staging-path PoC was run.
There is no CVE ID in the primary WordPress notes we fetched.
8.1 is Wordfence. WordPress.org did not publish CVSS.
18,500 requests / 9-minute first hit / 14.5-hour polling are Wordfence's numbers, 29 October. We did not reproduce the telemetry.
Wordfence has not claimed a confirmed compromise.
"Seconds-long window" is their lab observation.
CISA KEV status: not listed in the sources above. Absence from this post is not a CISA statement.

Sources

[1] https://wordpress.org/news/2026/10/wordpress-7-1-4/ - WordPress 7.1.4, 28 Oct 2026 17:13 UTC [2] https://wordpress.org/documentation/wordpress-version/version-7-1-4/ - HelpHub 7.1.4, branch floors [3] https://www.wordfence.com/blog/2026/10/wordpress-7-1-4-security-release-rce/ - Wordfence, 29 Oct 2026 [4] https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/ - SecurityWeek, 30 Oct 2026 [5] https://wordpress.org/download/releases/ - 7.1.4 zip dated 28 Oct 2026