WordPress released version 7.1.4 on October 29 to fix a critical unauthenticated remote code execution flaw in its core upgrade process, after Wordfence reported that attackers were already probing for it. The security firm recorded more than 18,500 malicious requests against staged installer paths within 21 hours.
How the WordPress Core Upgrade Staging Flaw Works
The flaw carries a CVSS score of 8.1, and MITRE had not assigned it a CVE at the time of Wordfence’s warning. It affects WordPress Core versions 4.7 through 7.1.3 during full-package core upgrades.
The cause is a predictable, web-accessible staging directory under wp-content/upgrade, which WordPress uses while it unpacks a core upgrade. An attacker who requests the staged setup-config.php file while unpacking is under way can execute PHP code on the site.
A Window of Seconds Drives Repeated Polling
In lab tests the window of exposure lasts only seconds. Because the timing is so narrow, attackers run scripts that repeatedly poll sites during upgrade windows, waiting for the moment the staged file becomes reachable. Exploitation therefore needs precise timing, which limits how many sites an attacker can compromise at once, although the sheer number of requests Wordfence recorded shows the scripts are running at volume.
Wordfence did not confirm a working public proof of concept. Researcher Umut Bayram found the issue.
What WordPress 7.1.4 Changes in the Update Process
WordPress 7.1.4 randomizes the staging directory, so attackers can no longer guess the path, and adds index protection to it. The fix is backported to branches going back to 4.7. Sites on version 4.6 and earlier receive no patches.
The release also fixes 21 other vulnerabilities. Those include stored cross-site scripting flaws in the block editor and in the Interactivity API.
Confirming the Update in the Dashboard
Administrators can confirm they are on the fixed release, or on the backported release for their branch, from the Dashboard under Updates. Wordfence’s warning stresses that the vulnerable moment arrives during an upgrade, so a site on 7.1.3 or earlier that begins a full-package core upgrade is the scenario attackers are polling for.
Scale of Exposure Across the WordPress Ecosystem
WordPress runs over 43% of websites, according to W3Techs figures cited by the source. That footprint gives the flaw potentially large exposure, even though the need for precise timing during an upgrade narrows the practical attack surface.
The volume of requests against staged installer paths shows attackers moved quickly after the issue became known. The 18,500 figure counts malicious requests, not successful compromises, and Wordfence has not reported how many sites were taken over.
Open Questions: CVE Assignment and Exploit Availability
Two items remain unresolved in the reporting. MITRE had not yet issued a CVE identifier when Wordfence published its warning, which means tracking records for the flaw may change as the identifier is assigned. And although no working public proof of concept has been confirmed, the observed scanning suggests attackers have built their own tooling.
The release thus closes a design weakness in how WordPress stages core upgrades, rather than a bug in a plugin or theme. The fix addresses the predictable path directly, while the 21 additional vulnerabilities patched in the same release add to the reasons the 7.1.4 package carries weight beyond the single remote code execution issue.
Wordfence Warning and WordPress 7.1.4 Release Arrived the Same Day
Wordfence published its warning on October 29, the same day WordPress shipped 7.1.4, so the exploitation attempts and the fix surfaced together. The 18,500 requests logged within 21 hours represent a sustained flow of probing aimed at the staged installer paths. Wordfence credited Umut Bayram with finding the issue.
The backport reaches branches down to 4.7. Versions 4.6 and earlier sit outside it and receive no patches, which leaves sites on those releases without a fix from the project.
