Update to WordPress 7.1.4 now. The October 28, 2026 security release fixes 22 vulnerabilities in WordPress Core, and its most serious flaw lets an unauthenticated attacker run code on a server during the brief window when a full-package Core update is unpacking. Wordfence blocked 62,969 attack attempts aimed at this flaw in a single 24-hour period after the patch shipped, so this is not a theoretical risk to deal with later. If your site runs WordPress 4.7 through 7.1.3, it is affected, and the fix is already available.
What happened
WordPress released version 7.1.4 on October 28, 2026 as a security release covering 22 vulnerabilities. The headline issue is a race condition in the Core update process, reported by researcher Umut Bayram. WordPress has not assigned it a CVE identifier yet, and as of October 30 it had not appeared in the CISA Known Exploited Vulnerabilities catalog. That absence should not be read as safety. Wordfence, the security company behind the Wordfence firewall plugin, deployed a blocking rule about three hours after the release, at 20:30 UTC on October 28, and saw its first matching request nine minutes later. In the first 21 hours it counted more than 18,500 requests aimed at staged installer paths, and the total later reached 62,969 blocked attempts in 24 hours.
The rest of the release matters too. Alongside the remote code execution flaw, version 7.1.4 addresses stored cross-site scripting issues, information disclosure, authorization weaknesses, denial of service problems, and interactivity API issues. It also updates bundled root certificates following the recent eMudhra revocation. Sites on older branches received backported fixes through WordPress 4.7, but only the latest release gets full active support, so moving to 7.1.4 is the cleanest option for most site owners.
How the upgrade-window flaw works
When WordPress performs a full-package Core update, it unpacks the new files into a staging directory under wp-content/upgrade. On affected versions, that staging path was predictable, and the staged copy included the WordPress installer files. On many servers, the staging directory was also reachable from the web and able to run PHP.
That combination creates a race. If an attacker requests the staged installer at exactly the right moment, before WordPress finishes the update and cleans up the temporary files, they can interact with the staged copy and progress to PHP code execution on the server. No account on the site is needed. In Wordfence lab tests, the window normally lasted only seconds, which is why the attack is described as high complexity despite its CVSS score of 8.1. Attackers compensate for the narrow window by polling relentlessly. Wordfence reported that two of the largest sources repeatedly probed small groups of sites for roughly 14.5 hours, while other sources tested many staging-directory and version-name variations.
It is important to be precise about what the attack numbers mean. The 62,969 figure counts blocked requests and probes, not 62,969 hacked websites. Wordfence has reported exploitation attempts, not confirmed compromises from this flaw. The numbers still matter, because they show attackers understood the race condition within minutes of the patch and started hunting for upgrade windows immediately. Any site that runs a full-package update while still on an affected version gives those probes a chance to land.
Who is affected
Every site running WordPress Core from version 4.7 through 7.1.3 is affected by the upgrade-window flaw, according to Wordfence. The patched releases are 7.1.4 for the latest branch, plus backports including 7.0.8, 6.9.11, 6.8.12, and 4.7.39 for older branches. Successful exploitation also needs specific conditions: a full-package update containing 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 removes the temporary files.
One detail deserves attention if you run Wordfence. Because the attack requests a staged PHP file directly, without loading WordPress first, a standard firewall setup that loads through WordPress may not see it. Wordfence recommends Extended Protection, which runs the firewall before directly requested PHP files execute. Premium, Care, and Response customers received the new rule on October 28. Free users are scheduled to receive it on November 27, 2026, after the standard 30-day delay, which makes updating promptly even more important for free-tier sites.
WordPress sites are a frequent target in general, not just for Core flaws. Plugin vulnerabilities have repeatedly put large numbers of sites at risk this year, including a critical flaw in the Bricksforge plugin and a SQL injection issue in Backuply that affected hundreds of thousands of installations. Keeping Core, themes, and plugins updated together is the baseline, not an optional extra.
What to do right now
Start with the update itself. Go to Dashboard, then Updates, in your WordPress admin area and confirm the site is running WordPress 7.1.4 or the patched release for its branch. Sites with automatic background updates enabled should already have started updating, but verify rather than assume, especially if your host delays automatic updates or if you manage updates manually.
Next, check for signs of trouble. Look in your access logs for suspicious requests to PHP files under wp-content/upgrade, particularly setup-config.php. In the admin area, look for unfamiliar administrator accounts, plugins you did not install, and PHP files in upload or theme directories that you cannot account for. If anything looks off, treat the site as potentially compromised and get help from your host or a security professional before simply cleaning up files, since a hidden backdoor can survive a surface cleanup.
Then harden the update path. Confirm that wp-content/upgrade is not browsable from the web. A 403 Forbidden response when requesting that directory is the result you want. If your server allows directory listings there, add a web server rule to block access to it. Keep automatic updates enabled for minor Core releases so future security fixes land without delay, and review your backup routine now, while the site is healthy, rather than discovering a backup gap during an incident.
Finally, update everything else while you are in maintenance mode. Themes and plugins with known flaws are still the most common way WordPress sites get compromised, and a patched Core does not protect an outdated plugin. Run a full backup before updating, update in a staging environment first if the site is business-critical, and test key pages and forms after the update.
What the fix changes
WordPress 7.1.4 changes the update process in three ways that close the race window. The staging directory is now randomized, so its path is much harder to predict. An index guard is added to block access to exposed staging files. And the update process no longer promotes staged configuration data unsafely. Together, these changes mean an attacker can no longer reliably guess where the staged installer lives or reach it during an update.
That fix does not retroactively protect updates that already ran on a vulnerable version. If your site performed a full-package update in the days before patching, and attackers were polling it at the time, the logs are worth a look. Going forward, the randomized staging path plus the index guard should make this particular race far harder to win, but the broader lesson stands: update windows are sensitive moments, and attackers watch release announcements as closely as administrators do.
Why this release deserves urgent attention
Some security releases can wait for a scheduled maintenance window. This one should not. The flaw needs no login, the patch was public on October 28, attackers began probing within minutes, and tens of thousands of attempts followed within a day. The race window is narrow, but attackers are patient and automated, and they only need to win it once. The fix is a routine Core update, not a risky migration, so there is little reason to delay.
WordPress powers a huge share of the web, which is exactly why its Core update process is such a valuable target. A flaw that only works during an update sounds like an edge case until you remember that millions of sites update, and that attackers can simply wait and poll. Patching to 7.1.4 closes this hole and 21 others at the same time. Do it today, verify the version number, and check the logs.
Frequently asked questions
Does WordPress 7.1.4 fix the remote code execution flaw?
Yes. WordPress 7.1.4, released October 28, 2026, fixes the unauthenticated upgrade-window remote code execution flaw, along with 21 other security issues. Older branches received backported fixes, including 7.0.8 and 4.7.39, but 7.1.4 is the recommended version for most sites.
Which WordPress versions are affected?
WordPress Core versions 4.7 through 7.1.3 are affected by the upgrade-window flaw, according to Wordfence. The flaw carries a CVSS score of 8.1 and has no CVE identifier assigned yet.
Do I need an account to exploit this flaw?
No. The flaw is unauthenticated, meaning an attacker needs no account on the target site. Successful exploitation still requires winning a narrow race during a full-package Core update, when staged installer files are unpacked under wp-content/upgrade.
Have any sites actually been hacked through this flaw?
Wordfence has reported tens of thousands of exploitation attempts, including 62,969 blocked requests in 24 hours, but has not reported confirmed compromises from this flaw. Treat the attempts as a strong reason to patch, not as proof that any particular site was breached.
How do I check whether my site is patched?
Go to Dashboard, then Updates, in WordPress admin and confirm the version shown is 7.1.4 or the patched release for your branch. Also confirm that wp-content/upgrade is not browsable from the web, and check logs for suspicious requests to PHP files under that directory.
What if I use Wordfence Free?
Wordfence Free users receive the new firewall rule on November 27, 2026, after the standard 30-day delay, while Premium, Care, and Response customers received it on October 28. Until then, updating to WordPress 7.1.4 is your main protection, and enabling Extended Protection helps the firewall block direct PHP requests.
For context on how WordPress flaws are usually handled, see our coverage of the Bricksforge WordPress flaw and the Backuply SQL injection issue. If you run other open source platforms too, the recent Drupal critical RCE is a useful reminder to patch promptly, and the GitLab CVSS 10.0 flaw shows why an earlier patch does not always close the hole.