WordPress 7.1.4 fixes core RCE amid active attack probes
WordPress 7.1.4 was released on October 28, 2026, with fixes for 22 security vulnerabilities, including an unauthenticated remote code execution (RCE) flaw, which could let an attacker run code on a server without first signing in. Wordfence reports that attackers began probing for the vulnerability shortly after the security release. Site owners should confirm that WordPress has installed version 7.1.4 or the corresponding security update for their older branch rather than assuming the automatic update succeeded.
The most serious issue affects WordPress Core versions 4.7 through 7.1.3 and has a CVSS score of 8.1, rated High. CVSS, or Common Vulnerability Scoring System, is a standard scale used to describe a security flaw's severity. The vulnerability is a race condition, meaning an attacker must act during a short period when two processes overlap. No site account is required, but the attacker must catch WordPress while it is unpacking a complete Core update.
During that type of update, vulnerable versions extract new WordPress files into a predictable directory beneath wp-content/upgrade. This staging directory, a temporary location used before new files go live, includes the WordPress installer. On many servers it can be reached from the public web. An attacker who finds or predicts the path can repeatedly request the staged setup-config.php file and interact with the temporary installation before WordPress removes it. PHP is the server-side programming language used to run WordPress, and reaching this staged PHP file can ultimately allow code execution on the host.
Several conditions must align. WordPress must be processing a full package containing installer files, the temporary directory must permit public web and PHP access, the path must be predictable or discovered, and the attacker must finish before cleanup. Wordfence says laboratory testing found that the vulnerable directory generally remained available for only seconds. A single request is therefore unlikely to succeed, but automated polling can repeatedly test a site in an attempt to hit the opening.
WordPress 7.1.4 changes that process by randomizing the staging directory, placing an index guard in it and blocking unsafe promotion of staged configuration data. Fixes were also backported as far as WordPress 4.7. The patched versions are 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 and 7.1.4. WordPress 4.6 and earlier no longer receive security updates and need to be moved to a supported release.
Active probing began quickly. Wordfence deployed a new firewall rule at 20:30 UTC on October 28, approximately three hours after the WordPress security release. A firewall filters potentially malicious requests before they reach a site. Wordfence Premium, Care and Response customers received the rule immediately, while Wordfence Free users are scheduled to receive it on November 27, 2026, after the standard 30-day delay.
Wordfence recorded the first match for that rule nine minutes after deployment. Over its first 21 hours, the company's telemetry, meaning security event data collected from protected sites, counted more than 18,500 requests aimed at staged setup-config.php paths. Two of the largest sources repeatedly polled small sets of sites for about 14.5 hours. Other sources tried numerous staging-directory and version-name combinations. Wordfence notes that not every request used the precise vulnerable path, but says the sustained polling and exact directory layouts show that attackers had understood and started targeting the timing flaw. The report does not state that every probe succeeded.
The firewall rule has an important deployment requirement. The malicious request goes straight to a staged PHP file without loading WordPress first. Sites using Wordfence therefore need its Extended Protection mode, which starts the firewall before direct PHP requests reach the requested file. A firewall rule can reduce exposure, but it does not remove the vulnerable Core behavior and is not a substitute for installing a patched version.
The other fixes in WordPress 7.1.4 cover several security classes. Multiple stored cross-site scripting (XSS) flaws, where harmful browser code is saved on a site and later shown to another user, involved block delimiters, the Categories block, Comments Pagination and Post Navigation labels, Customizer selective refresh, personal-data erasure requests, specially constructed usernames, and Image and Playlist block processing. Some require a Contributor, Author or Editor account, and several also depend on a more privileged user viewing attacker-controlled content. Those requirements limit exposure compared with the unauthenticated RCE, but stored XSS can still cause account takeover or unauthorized site changes.
The release also corrects Interactivity API problems involving unsafe URL, event-handler, internal-property and object bindings. An API is a defined way for software components to exchange instructions or data. Additional fixes cover prototype pollution, where input changes properties inherited by other software objects, Script Module data shadowing, uploaded text-file processing in the Interactivity Router and a persistent denial of service condition, which can keep a service unavailable by exhausting or blocking its resources.
Further patches address unauthenticated disclosure of unpublished Customizer changesets and an authorization weakness in the Notes REST API. That permissions issue affected custom roles allowed to moderate comments but not edit the post carrying a note. Bundled root certificates, which help software decide which encrypted connections to trust, were also updated following the eMudhra revocation.
Owners whose sites stayed unpatched should review requests to PHP files beneath wp-content/upgrade and check for unfamiliar administrator accounts, unexpected plugins or PHP files they did not add. Wordfence also recommends running a scan after updating to identify modified Core files, malicious files or other evidence requiring investigation. For site owners reviewing where responsibility for WordPress security sits, AEU Hosting provides managed WordPress hosting secured end to end.
The immediate priority is to open Dashboard > Updates and verify the installed release. Automatic background updates should deliver the fix to most sites, but a failed or delayed update would leave the vulnerable upgrade behavior in place. Confirming the version, checking for suspicious activity and investigating unexpected changes are necessary because active attackers are already trying to catch the brief update window.