WordPress Core Has a Remote Code Execution Bug in Its Own Update Window. Update to 7.1.4, and Here Is What Our Edge Did and Did Not See.
If you run WordPress 4.7 through 7.1.3, update to 7.1.4, released October 28. Wordfence found that the core updater leaves a window in which an unauthenticated visitor can reach code execution. Wordfence blocked 62,969 attacks against it in 24 hours. The advisory has no CVE; it is GitHub advisory GHSA-4w3m-c66w-69mg, rated CVSS 8.1.
How the bug works
During a full-package core update, affected versions unpack the new files into a predictable directory under wp-content/upgrade. That staged copy includes the WordPress installer, and many servers serve it to the public. An unauthenticated attacker who requests the installer at the right moment can interact with the staged copy and progress to PHP code execution. In lab tests, as reported, the window lasted only seconds.
It takes all four of these at once: a full-package update that includes the installer files, public web and PHP access to the staging tree, a predictable or discoverable staging path, and enough time before WordPress deletes the temporary files. That is why most sites are exposed only briefly, and why attackers poll.
What the attackers did
Wordfence reports the repeated polling of setup-config.php, and some requests that did not use the exact vulnerable path but tried many staging-directory and version-name variations. Two of the largest sources polled small groups of sites for about 14.5 hours, which fits an attacker waiting for an update window to open.
What to do
From the report: update to 7.1.4, look for suspicious requests to PHP files under wp-content/upgrade, and check for unfamiliar administrator accounts, plugins or PHP files.
Ours, not Wordfence's:
- Keep the staging tree off the web. If your server can refuse requests to wp-content/upgrade, do it. It removes one of the four conditions.
- Do not leave a site mid-update. A stalled or failed update is the longest window you can give an attacker.
- Read the access logs from October 28 backward, not only forward. The reported activity predates the fix by an unknown margin.
What our edge saw
We ran our edge telemetry check for the two paths in the reports, from October 1. Edge blocks: 41,574 documents scanned, no match. Edge canaries, which answer trapped paths with a decoy: 26,646 scanned, 14 hits from 14 IP addresses on /wp-admin/setup-config.php, first on October 2 and last on October 31, three of them after the October 28 release. Origin honeypot, which only sees what got past the edge: 1,384 scanned, three hits on /wp-content/upgrade/index.php on October 12, 15 and 27, all before the release.
How to read that: setup-config.php under wp-admin is the ordinary installer path that scanners hit constantly, and an index.php inside the upgrade directory is a common directory probe. None of what we logged shows the staging-directory variations Wordfence describes, so we have no evidence of this exploit against us. It is also not proof of absence: our canaries only fire on paths we trap, and a quiet edge does not mean nobody is scanning.
What we hold, and what we don't
Nothing for the feed. The report publishes no IP addresses, user agents, domains or payloads, so there is nothing to ingest.
Limits
We rely on The Hacker News' October 30 summary of Wordfence's findings and did not read Wordfence's advisory or reproduce the bug. The attack count is Wordfence's own figure for its customers.
Five percent of this is wrong somewhere. It always is. The numbers will move again before you finish reading.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.