What happened

WordPress released version 7.1.4 on October 28, 2026 as a security release. Among the fixes, the WordPress announcement lists a weakness in the upgrade process that can lead to remote code execution during the upgrade window. The fix was backported to all branches that receive security fixes, currently back to 4.7, and the project says backports ship as they become ready.

According to reporting by The Hacker News and the Wordfence team, the issue has no CVE identifier at the time of writing and carries a CVSS score of 8.1. Affected versions are WordPress Core 4.7 through 7.1.3. Wordfence describes the cause as predictable, web-accessible staging paths used during full-package core upgrades. The new files, including the WordPress installer, are unpacked into a predictable directory under wp-content/upgrade. If that directory is reachable over the web, an unauthenticated visitor who requests the installer at the right moment can interact with the staged copy and progress to PHP code execution.

Wordfence lists the conditions for exploitation: a full-package update that contains the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time to finish before WordPress cleans up the temporary files. In lab conditions the window lasts only seconds.

That has not stopped attackers. Wordfence reports blocking 62,969 attempts in 24 hours. Two of the largest sources repeatedly polled small groups of sites for about 14.5 hours, which fits a race for the short upgrade window, and others tried many staging-directory and version-name variations.

Why it matters

Two things make this more than a routine core release. First, it affects a very wide range of versions, and the trigger is a normal maintenance action: updating WordPress. Second, exploitation is a race, which means attackers do not need credentials, only patience and a sustained polling loop. Sites that update on a schedule and sit behind a web server with default permissions are the natural targets.

The narrow window lowers the chance of success per attempt, not the risk over time. Anyone who updates core regularly gives a poller repeated chances. We are not aware of confirmed compromises from public sources at the time of writing, only large scale attempts, so treat any hit as a lead to verify, not proof of compromise.

What defenders should check

  • Version: confirm every WordPress instance you own is on 7.1.4 or the backported release for its branch. Use wp core version or the admin dashboard.
  • Exposure: from outside your network, request /wp-content/upgrade/ and see whether the web server serves anything. A 403 or 404 is the goal.
  • Inventory: agencies and hosting providers often run forgotten WordPress copies. Search your asset inventory and external scans for the WordPress component, then verify versions. A Shodan style starting point is http.component:"WordPress" scoped to your organization, but a scan only shows what is exposed, not always the version.
  • Update process: if you update by full package, make sure the staging path is not reachable while you do it, or block it at the web server first.
  • Backups and file integrity: make sure you have a recent known good copy to compare against.

Detection ideas

The snippets below are starting points to adapt and test in your environment. They are not production-ready rules.

Web server access logs (nginx or Apache):

grep -E "wp-content/upgrade/.*\\.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
grep -E "setup-config\\.php" /var/log/nginx/access.log | grep "wp-content/upgrade"

KQL style query for web logs ingested into a SIEM (adapt table and field names):

WebLogs
| where UrlPath has "/wp-content/upgrade/" and UrlPath endswith ".php"
| summarize Requests=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by ClientIP, UrlPath
| order by Requests desc

File system checks for PHP files that should not be there:

find /var/www -type f -name "*.php" -mtime -3 -not -path "*/wp-content/cache/*"
find /var/www -path "*/wp-content/upgrade/*" -type f

Look for many requests from one source across multiple sites, repeated for hours, with changing directory names. That pattern matches the polling behavior Wordfence describes.

Investigation

If you see requests to PHP files under wp-content/upgrade that returned HTTP 200, or you cannot rule out an exposed update window, collect evidence before cleaning up:

  • Web server access and error logs covering the days around your last core update, plus PHP-FPM logs.
  • A file listing with modification and creation times for the whole web root, and hashes of PHP files compared against a clean copy of the same WordPress version.
  • The wp_users table (new administrators), the active plugin list, and the wp_options table for unexpected entries.
  • Scheduled tasks: WordPress cron entries and system crontabs of the web user.
  • Outbound connections from the web server host around the suspected time.
  • A disk or snapshot image if the host may be part of a wider incident, so the evidence stays intact.

If you want help scoping this, our incident response and compromise assessment work covers this kind of web server investigation.

Mitigation

  • Update to WordPress 7.1.4, or the backported release for your branch, as soon as possible. The release notes recommend updating immediately.
  • Block public web access to wp-content/upgrade at the web server or reverse proxy as defense in depth, and remove the rule only if it breaks a legitimate workflow.
  • Keep automatic updates on unless you can replace them with a monitored, fast manual process.
  • Remove unknown admin users, plugins and PHP files after you have preserved evidence, and rotate WordPress salts, database credentials and any secrets stored on the host if compromise is confirmed.
  • Put a web application firewall rule in front of the site as a stopgap, and keep logging so you can review it later.

Sources: WordPress.org announcement for 7.1.4 (October 28, 2026); Wordfence Threat Intelligence write-up and The Hacker News coverage, which are the basis for the attempt counts and the exploitation conditions above.