<\/p>\n
The safest moment in a WordPress site’s life is supposed to be the moment it updates. This week we learned that, for a few seconds, that moment was the dangerous one \u2014 and attackers figured it out within minutes.<\/p>\n
On October 28, WordPress released version 7.1.4, a security release fixing 22 vulnerabilities, according to Wordfence. The most serious one has no account requirement at all: an unauthenticated race condition in the Core update process that can lead to remote code execution. Wordfence scores it 8.1 out of 10, High, and says it affects WordPress Core versions 4.7 through 7.1.3.<\/p>\n
Here is the mechanism, in plain terms. When WordPress installs a full-package Core update, it unpacks the new files into a staging directory under The catch for the attacker is timing. Wordfence says that in normal lab environments the staging directory is available for only seconds, before WordPress cleans up the temporary files. Winning that race takes 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 cleanup. That is a real list of conditions \u2014 and it did not slow anyone down.<\/p>\n Wordfence deployed a firewall rule for this flaw on October 28 at 20:30 UTC, about three hours after the release was announced. The first attack matching that rule arrived nine minutes later. In the first 21 hours, Wordfence recorded more than 18,500 requests targeting staged The behavior matches the bug. Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours \u2014 exactly what you do when you are waiting for a seconds-long window to open. Other sources tested many staging-directory and version-name variations. Nobody wins this race by luck. They win it by asking, over and over, until a site happens to be mid-update.<\/p>\n Serious, but keep it in proportion. The impact if an attacker wins is as bad as it gets \u2014 code running on your server, no login needed. The probability on any single update is low, because the window is seconds and the conditions have to line up. What pushes the risk up is repetition and automation: polling is free, sites update regularly, and every full-package update on an unpatched version opens the window again.<\/p>\n Also be precise about what the numbers mean. Those tens of thousands of blocked requests are attempts, not break-ins. The sources I read report active exploitation attempts; they do not report a confirmed compromise from this flaw. Treat a hit in your logs as a reason to look, not as proof you were breached.<\/p>\n One more wrinkle matters if you rely on Wordfence Free, as plenty of small sites do. Premium, Care, and Response customers got the new firewall rule on October 28. Free users get it on November 27, after the standard 30-day delay. Until then, the patch \u2014 not the firewall rule \u2014 is what protects a free site. Wordfence also notes that because this attack requests a PHP file directly, without loading WordPress first, sites using its firewall should confirm Extended Protection is enabled.<\/p>\n First, do not assume the auto-update landed \u2014 verify it. Go to Dashboard, then Updates, and confirm your site is running WordPress 7.1.4 or the corresponding patched release for your branch. The fix was backported through WordPress 4.7, so older branches have their own patched versions; WordPress 4.6 and earlier no longer receive security updates at all and need a real upgrade, not a patch. The fix itself randomizes the staging directory, adds an index guard, and stops staged configuration data from being promoted unsafely.<\/p>\n Second, patching closes the hole, but it does not answer whether someone got in before you patched. If your site sat unpatched, look for suspicious requests to PHP files under Third, keep the boring rule that prevents the next one of these: leave automatic updates on for Core, plugins, and themes. I run several WordPress sites, and the lesson I take from a nine-minute gap between a firewall rule and the first attack is that there is no grace period anymore. The time between “patch released” and “someone is actively trying it” is now measured in minutes, and the only schedule that keeps up with that is the one that updates without waiting for me.<\/p>\n Update today, verify the version number with your own eyes, and check the upgrade folder in your logs. That is the whole job \u2014 and right now, it is genuinely enough.<\/p>\n Sources: Wordfence, “WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release” (October 29, 2026) \u2014 wordfence.com\/blog\/2026\/10\/wordpress-7-1-4-security-release-rce<\/a>; The Hacker News, “WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours” (October 30, 2026) \u2014 thehackernews.com\/2026\/10\/wordpress-rce-flaw-draws-nearly-63000<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" The safest moment in a WordPress site’s life is supposed to be the moment it updates. This week we learned that, for a few seconds, that moment was the dangerous one \u2014 and attackers figured it out within minutes. What happened On October 28, WordPress released version 7.1.4, a security release fixing 22 vulnerabilities, according […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-166","post","type-post","status-publish","format-standard","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/166","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/comments?post=166"}],"version-history":[{"count":0,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/166\/revisions"}],"wp:attachment":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/media?parent=166"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/categories?post=166"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/tags?post=166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}wp-content\/upgrade<\/code>. That staged copy includes the WordPress installer, the staging path is predictable, and on many servers it is reachable from the web. If an attacker with no account on your site at all requests that installer at exactly the right moment, they can interact with the staged copy and work their way to running PHP code on your server.<\/p>\nAttackers did not wait<\/h2>\n
setup-config.php<\/code> installer paths. By the time The Hacker News reported the story on October 30, Wordfence said it had blocked 62,969 attacks targeting the vulnerability in 24 hours.<\/p>\nHow bad is it, honestly?<\/h2>\n
What to actually do<\/h2>\n
wp-content\/upgrade<\/code>, unfamiliar administrator accounts, and plugins or PHP files you did not put there. Then run a full security scan after updating.<\/p>\n