A WordPress security patch went out on October 28, 2026. Within 24 hours, Wordfence had blocked 62,969 attempts to exploit the hole it fixes. That is the pace at which WordPress sites get attacked the moment a flaw becomes public.
This post explains what the WordPress core remote code execution flaw is, how attackers are racing to exploit it, and exactly what site owners should do today.
What the WordPress RCE Flaw Is
The vulnerability is a case of remote code execution in WordPress Core itself, not in a plugin or theme. It affects WordPress Core versions 4.7 through 7.1.3 and carries a CVSS score of 8.1. It does not have a CVE identifier yet.
- Fixed in: WordPress 7.1.4, released October 28, 2026
- Impact: remote code execution on the server
- Access needed: none. The attacker does not need an account
- Reported by: the Wordfence Threat Response Team
The root cause is predictable, web-accessible staging paths used during full-package core upgrades. In plain terms, when WordPress updates itself, it unpacks the new version into a temporary folder that many servers leave open to the web, and that temporary copy includes the WordPress installer.
How the Attack Works
When WordPress runs a full-package update, it unpacks fresh files into a predictable directory under wp-content/upgrade. That staging copy includes setup-config.php, the installer file.
“Because the staging directory is web-accessible on many servers, an unauthenticated attacker who requests the installer at precisely the right moment can interact with the staged WordPress copy and progress to PHP code execution,” said Alex Thomas, who leads the Wordfence Threat Response Team.
It is a race condition. The window between the files appearing and WordPress cleaning them up has been measured in seconds in lab conditions. Attackers win the race by polling the vulnerable paths over and over until one request lands inside the window. Four conditions have to line up:
- A full-package update that includes the installer files
- Public web and PHP access to the staging directory
- A predictable or discoverable staging path
- Enough time to finish before WordPress deletes the temporary files
Why 63,000 Attack Attempts in 24 Hours
Wordfence blocked 62,969 attacks targeting this vulnerability in the first 24 hours after patches were released. The volume comes from the polling technique. Since the window is a matter of seconds, attackers script repeated requests and let them run.
Attackers have been probing paths such as setup-config.php again and again, along with variations of staging directory and version names. “Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window,” Thomas said.
His other observation is the worrying one: “Not every request used the exact vulnerable path, but the sustained polling and exact-layout probes show that attackers quickly understood the race condition and began targeting it.” The exploit knowledge spread within hours of the patch.
Are You Affected
You are in the affected range if your site runs any WordPress Core version from 4.7 through 7.1.3. That covers most sites that have not updated since October 28.
The practical risk depends on your hosting setup. Sites where wp-content/upgrade is publicly reachable over the web and PHP are the ones attackers can actually reach. Hardened hosts that block web access to the staging directory reduce the risk, but the only complete fix is updating.
One piece of good news: the attack can only land during an upgrade window. If you are not running a full-package update, the staged installer is not there to hit. But since attackers poll around the clock, any site that updates automatically is a target at the moment it updates.
How to Protect Your WordPress Site
- Update to WordPress 7.1.4 now. This is the only complete fix. Do it through your dashboard or with wp-cli:
wp core update. - Check for suspicious requests. Look through your web server logs for requests to PHP files under wp-content/upgrade, especially setup-config.php. Any hits from unfamiliar IPs are probing attempts.
- Look for signs of compromise. Wordfence advises checking for unfamiliar administrator accounts, plugins you did not install, and PHP files where they should not be.
- Restrict web access to the staging directory. If your host allows it, block HTTP access to wp-content/upgrade at the server level. It removes the attack surface entirely.
- Keep auto-updates on. The race window exists only during upgrades, but the fix also arrives through upgrades. Fast patching is the winning strategy here.
What Happens Next
Attack volumes will stay high while millions of sites remain in the affected version range. Expect scanning for setup-config.php to continue for weeks, since old WordPress installs linger on the web for a long time. A CVE identifier will likely be assigned, and hosting companies are expected to push forced updates to vulnerable sites.
What To Do If You Think You Were Hit
Speed matters more than perfection if you suspect a compromise. The goal is to remove attacker access before it is used.
- Take the site offline briefly. A maintenance page for an hour is cheaper than cleaning a server that is actively being controlled.
- Restore files from a known clean backup taken before October 28, then update to 7.1.4 immediately after restoring.
- Rotate every credential. WordPress admin passwords, database passwords, FTP and SSH accounts, and the salts and keys in wp-config.php.
- Reinstall core, plugins and themes from official sources. Do not trust the files currently on the server.
- Scan once more after cleanup. A fresh scan of logs and files confirms the reinstall closed the door.
If you are on managed hosting, open a ticket early. Hosts see this attack across thousands of sites and usually know the exact probe patterns to search for in their logs.
The Bigger Lesson
The bigger lesson is about timing. The gap between a patch and mass exploitation is now measured in hours. For WordPress site owners, update speed is the single most valuable security setting.
FAQ
Which WordPress versions are affected by the RCE flaw?
WordPress Core versions 4.7 through 7.1.3 are affected. The flaw is fixed in WordPress 7.1.4, released on October 28, 2026. It is a core issue, so updating the core is what fixes it.
Is the WordPress core RCE being exploited in the wild?
Yes. Wordfence blocked 62,969 exploitation attempts in the first 24 hours after the patch. Attackers are polling predictable staging paths like setup-config.php in long-running loops, hoping to hit the brief window during a full-package upgrade.
How do I check if my WordPress site was hacked?
Check your server logs for requests to PHP files under wp-content/upgrade, then look in your admin panel for administrator accounts, plugins or themes you did not add, and unfamiliar PHP files in your directories. If anything looks wrong, restore from a clean backup and change all credentials.
What is wp-content/upgrade used for?
It is WordPress’s staging folder for core upgrades. During a full-package update, new core files, including the installer, are unpacked there before being moved into place. On many servers this folder is reachable from the web, which is what makes the race condition exploitable.
The one-line takeaway: the patch is already out and the attacks are already running, so updating to WordPress 7.1.4 today is worth more than any scanner you can install tomorrow.
