WordPress site owners are facing a wave of automated probing against a freshly disclosed remote code execution flaw that can briefly expose a hidden installer during the platform’s own update process. Threat intelligence from security firm Wordfence recorded 60,471 blocked attack attempts against the flaw in a single 24-hour window.

A Patch That Arrived Just in Time

WordPress shipped version 7.1.4 on October 28, 2026, resolving 22 separate security issues in one release. Alongside the headline remote code execution bug, the update also closed stored cross-site scripting flaws, an information disclosure issue, and several permission-handling bugs. WordPress’s own advisory urges administrators to update without delay and credits researcher Umut Bayram with reporting the flaw that triggered the emergency fix.

It is worth being precise about what the attack numbers actually represent: Wordfence’s figure reflects blocked requests, not confirmed break-ins. A large volume of attack traffic shows that opportunistic scanners and bots are actively testing for the vulnerability — it does not, on its own, prove that tens of thousands of individual sites have been compromised.

Why the Flaw Is Hard to Exploit — But Not Impossible

The vulnerability is a race condition, a category of bug where an attacker has to act within a very specific, often extremely short window of time rather than simply authenticate or send a crafted request whenever they like. Notably, no login or stolen credentials are required to attempt exploitation — but success depends on catching a site in the middle of a full WordPress Core upgrade.

During that process, WordPress temporarily unpacks its update files into a staging folder with a predictable name. If that folder, and the installer files inside it, briefly become reachable from the public internet, an attacker who catches the window could point the exposed installer at a database server they control — potentially opening a path to executing their own code on the target server.

The patch addresses this by appending 16 random characters to the temporary folder name so it can no longer be guessed, restoring protective index.php files that had been missing, and preventing the wp-config.php configuration file from being copied out of the working directory during the update. In other words, the fix closes the exposure window itself rather than patching a specific plugin or theme.

Because the vulnerable window typically lasts only a matter of seconds per site, successful exploitation is difficult — but far from impossible, especially at scale. Each additional request an attacker fires off is another small chance of catching a site mid-update, and Wordfence has already logged exploitation attempts following the security release, confirming that attackers are actively testing the weakness despite the tight timing requirements.

Firewall Coverage Is Rolling Out Unevenly

Wordfence says its Premium, Care, and Response customers received a firewall rule covering the vulnerability within roughly three hours of the WordPress 7.1.4 release on October 28. Free-tier users, however, are on the standard 30-day delay schedule and won’t receive that same protection until November 27 — nearly a month after the patch became public knowledge. Wordfence is explicit that site owners should not wait for that firewall rule to arrive before applying the official patch.

What Site Owners Should Do Now

• Open the WordPress Dashboard, go to Updates, and confirm the installation is running version 7.1.4 (or the matching backport for an older branch, such as 7.0.8 or 6.9.11 — security backports extend as far back as 4.7.39)
• Don’t rely solely on automatic background updates — verify the update actually completed rather than assuming the site is protected
• Be aware that WordPress versions 4.6 and earlier no longer receive security updates at all and need a full upgrade, not just a patch
• Consider restricting public web access to the wp-content/upgrade/ directory as an added layer of defense, since a plugin-level firewall may not reach the separately loaded installer

The core takeaway for administrators is straightforward: applying the WordPress 7.1.4 Core update is the only complete fix for this exposure. Firewall rules and access restrictions can reduce risk in the meantime, but they are not substitutes for closing the underlying flaw.