WordPress RCE Flaw Under Attack Hours After the 7.1.4 Patch: What Site Owners Need to Know

Attackers started going after a new WordPress Core vulnerability within hours of the fix being released. The flaw, patched in WordPress 7.1.4 on October 28, 2026, is a race condition in the core update process that can let an unauthenticated attacker run code on the server. It affects WordPress versions 4.7 through 7.1.3, and Wordfence has already blocked tens of thousands of attack attempts.

If you run a WordPress site, the short version is simple: check that you're on 7.1.4, or the patched release for your branch, today.

What happened

WordPress released version 7.1.4 on October 28, 2026, as a security update and recommended that everyone "update your sites immediately." The release fixes 12 security issues and updates bundled root certificates. The most serious fix covers what the WordPress team describes as a weakness in the upgrade process "that can lead to remote code execution during the upgrade window." It was reported by researcher Umut Bayram.

Wordfence, the WordPress security product from Defiant, rates the flaw 8.1 (high) on the CVSS scale. No CVE identifier has been assigned yet. The attack complexity is high, but no login is needed.

How the WordPress RCE flaw works

During a full-package core update, affected WordPress versions unpack the new files into a predictable folder under wp-content/upgrade. That staged copy includes the WordPress installer, such as setup-config.php. On many servers, that folder can be reached from the web.

Alex Thomas, who leads the Wordfence Threat Response Team, told The Hacker News that "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."

According to Wordfence, an attack only works if four conditions line up:

1. The site is running a full-package update that contains the installer files.

2. The staging folder is publicly reachable over the web and can execute PHP.

3. The attacker knows or can discover the staging path.

4. The attacker finishes before WordPress cleans up the temporary files.

That last condition is the hard part. Wordfence says the window lasted only seconds in its lab tests. That's why this is a race condition: the attacker has to hit the staged installer during the brief moment it exists.

Attackers moved fast

A narrow window hasn't stopped anyone from trying. Here's what Wordfence has reported:

• Rule deployed: Wordfence deployed its firewall rule at 20:30 UTC on October 28, about three hours after the security announcement, according to CyberPress.

• First hit: The first request matching the new rule arrived nine minutes after deployment.

• First 21 hours: Wordfence recorded more than 18,500 requests targeting staged setup-config.php installer paths.

• First 24 hours: Its vulnerability database reported 62,969 blocked attacks targeting the flaw, as cited by The Hacker News.

The behavior shows attackers understand the race. "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. "Other sources tested many staging-directory and version-name variations."

An important caveat: these are attempts, not confirmed break-ins. Wordfence hasn't reported any successful compromises. Thomas also noted that "not every request used the exact vulnerable path."

What the patch changes

According to Wordfence, WordPress 7.1.4 closes the hole in three ways:

• Random staging folders: The staging directory now has a random name, so attackers can't predict it.

• Index guard: A guard file blocks direct access to the folder's contents.

• Safer config handling: WordPress no longer promotes staged configuration data in an unsafe way.

WordPress says the fixes have been backported to every branch still eligible for security fixes, currently back to 4.7, and CyberPress reports this includes version 4.7.39. WordPress notes that only the newest version is actively supported, and that some backports will ship as they're ready.

The other fixes in WordPress 7.1.4

The RCE gets the headlines, but WordPress lists 11 other security fixes in this release. Most are stored cross-site scripting (XSS) bugs, including issues in:

• block markup, the Categories block, Playlist and image blocks, and comments-pagination blocks

• the Interactivity API, which also had a stored denial-of-service issue

• Customizer selective refresh

• Privacy Data Removal Requests and specially crafted user logins (both credited to Anthropic)

The release also fixes unpublished Customizer changesets being discoverable by logged-out users, and notes being readable by privileged users who can't edit the attached post. It updates bundled root certificates after the eMudhra revocation too. So even if your site is hard to hit with the race condition, the update is still worth installing.

What WordPress site owners should do now

1. Update today. Install WordPress 7.1.4, or the patched release for your branch, from Dashboard > Updates.

2. Don't assume auto-updates worked. Background updates should apply the fix automatically, but CyberPress, citing Wordfence, advises checking the installed version in Dashboard > Updates rather than assuming.

3. Check your logs. If your site updated before the fix, look for requests to PHP files under wp-content/upgrade, especially setup-config.php.

4. Look for signs of compromise. Review for unfamiliar administrator accounts, plugins you didn't install and unexpected PHP files.

5. Scan after updating. Wordfence recommends running a malware scan once you've patched.

6. Block PHP in the upgrade folder. As general hardening, many hosts block PHP execution under wp-content/upgrade, since that folder should never serve code to visitors. Test it on a staging site first.

If you use Wordfence's firewall, note the timing. Premium, Care and Response customers got the rule right away, while Free users are scheduled to get it on November 27, 2026. Wordfence also recommends enabling Extended Protection, because these requests go straight to staged PHP files without loading WordPress. Wordfence says plainly that a firewall rule doesn't replace installing the patched release.

Why it matters

WordPress runs a huge share of the web, so a flaw in core, rather than in one plugin, puts millions of sites in scope at once. This one is unusual because the risk comes from the update itself, the moment site owners usually think of as making things safer.

It's also another reminder of how quickly attackers turn patches into exploits. From release to the first attack attempts took hours, not weeks. We saw the same pattern with the PHP2Shell vulnerabilities in PHP web servers, and the same lesson applies: patch quickly, then verify. If you run WordPress in containers, our Docker update and rollout checklist shows how to confirm a fix actually reached every running instance.

Sources:

• WordPress 7.1.4 Security Release, WordPress.org, October 28, 2026

• WordPress 7.1.4 security release: RCE, Wordfence

• WordPress Core 4.7.0–7.1.3: Unauthenticated upgrade-window staged installer RCE, Wordfence Intelligence

• Fresh WordPress Vulnerability in Attackers' Crosshairs, SecurityWeek, October 30, 2026

• WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours, The Hacker News, October 30, 2026

• Hackers Actively Target WordPress RCE Flaw, CyberPress, October 30, 2026