KIungefiltert

· 3 min read · Auf Deutsch lesen

WordPress Core: RCE flaw in the update process draws nearly 63,000 attack attempts in 24 hours

A race condition in WordPress core updates allows unauthenticated code execution (4.7 to 7.1.3, CVSS 8.1, no CVE). Wordfence blocked nearly 63,000 attempts in 24 hours. Fix: 7.1.4 plus backports.

securityself-hosting

Translated from the German original with an AI language model, approved by me. Read the original

Shortly after WordPress shipped a security release on October 28, 2026, attackers started looking for sites that hadn't installed it yet. The flaw is in WordPress core itself, not in a plugin, and it affects versions 4.7 through 7.1.3. That covers most WordPress installations still running today.

What happened

The bug is a race condition, a flaw where the outcome depends on timing: whoever gets in at the right moment "wins the race." The WordPress 7.1.4 release notes describe it as "a race condition during core updates that could lead to remote code execution," reported by security researcher Umut Bayram. Remote code execution (RCE) means an attacker can run their own code on the server from anywhere.

Here's the rough picture. During a full-package core update, WordPress first unpacks the new files into a staging directory under wp-content/upgrade. That path is predictable, and on many servers it can be reached from the internet. The staged copy also contains the WordPress installer. According to The Hacker News, an attacker who reaches the installer during that short window can get all the way to PHP code execution, with no login required.

It's not trivial to pull off. Several conditions have to line up: a full-package update, public web and PHP access to the staging tree, a known or guessed path, and enough time before WordPress deletes the temporary files. In lab environments the directory existed for only a few seconds, heise Security reports, which is why SecurityWeek calls the attack complexity high. The flaw is rated CVSS 8.1 (high). No CVE number has been assigned so far.

The attack attempts

Security firm Wordfence (Defiant) says it blocked 62,969 attacks targeting this flaw within 24 hours. The first hit on its new firewall rule came nine minutes after the rule went live. In the first 21 hours alone, more than 18,500 requests went after the staged installer. Two of the most active sources kept polling small groups of sites for about 14.5 hours, apparently hoping to catch an update in progress.

The key distinction: these are attempts. None of the sources has reported a confirmed successful compromise so far.

What has changed since my post

We now know more about the fix. The current version is 7.1.4, and older branches get backports all the way down to 4.7.39, for example 7.0.8, 6.9.11 and 6.8.12. According to SecurityWeek, WordPress now randomizes the staging directory name, adds an index guard and no longer promotes configuration data from the staging area. Version 7.1.4 also fixes 22 other security issues, including several XSS bugs. Versions older than 4.7 no longer get any security updates.

Why it matters

What makes this flaw nasty is that it strikes at the exact moment you're doing the right thing: updating. As long as a site runs an affected version and the staging directory stays reachable, every future full-package core update opens that window again. The late-September WordPress flaw was also attacked within hours of disclosure. With WordPress, the gap between patch and attack is effectively zero.

What you should do now

  • Update: to 7.1.4 or the backport for your branch. Check under "Updates" in the dashboard which version is actually running.
  • Verify automatic updates: they are normally on for security releases, but hosts, configuration or file permissions sometimes block them. Don't assume they ran. Check.
  • Lock down the staging directory: Patchstack recommends denying web access to wp-content/upgrade/ and making sure the directory isn't listable.
  • Check your logs: look for suspicious requests to PHP files under wp-content/upgrade, especially if you updated after October 28.
  • Look for traces: unknown admin accounts, plugins nobody installed and PHP files that don't belong.

My advice: if you look after several WordPress sites, check every single one today instead of trusting that updates "run automatically." The attackers are checking every single one too.

Sources