WordPress site owners are under active attack right now, because threat actors have been observed attempting to exploit a high-severity security flaw in WordPress Core, and they are doing it just hours after patches were released.

The vulnerability does not have a CVE identifier assigned yet, it carries a CVSS score of 8.1, and it impacts WordPress Core versions 4.7 through 7.1.3. Patches for the flaw were released on October 28, 2026, in version 7.1.4, so if you have not updated yet, you need to do it immediately.

The Predictable Staging Path Problem

Here is exactly what is going wrong. When WordPress performs a full-package core update, it unpacks the new files into a predictable directory under wp-content/upgrade.

This copy of the update also includes the WordPress installer. Because this staging directory is web-accessible on many servers, an unauthenticated attacker can request the installer at precisely the right moment. If they get lucky, they can interact with the staged WordPress copy and progress to PHP code execution.

Wordfence's Alex Thomas described the exploit as requiring the attacker to hit a very narrow window while WordPress is unpacking a complete Core update.

The Race Condition

Successful exploitation requires a race condition, which means the attacker has to be faster than the server. But the window is absurdly small.

Wordfence observed that in normal lab environments, the window lasts only seconds. Threat actors are trying to win that race by polling vulnerable paths, such as setup-config.php, repeatedly.

The numbers tell the story. Over the past 24 hours, Wordfence said it has blocked 62,969 attacks targeting the vulnerability.

How Attackers Are Adapting

Thomas noted that two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours, which is behavior consistent with trying to catch the brief upgrade window.

Other sources tested many staging-directory and version-name variations. Not every request used the exact vulnerable path, but the sustained polling and exact-layout probes show that attackers quickly understood the race condition and began targeting it.

To pull off a successful exploit, several conditions must be met.

• The update must be a full-package update containing the installer files.
• The staging tree must have public web and PHP access.
• The attacker needs a predictable or discovered staging path.
• They need adequate time to complete the attack before WordPress cleans up the temporary files.

What Site Owners Must Do Right Now

With active exploitation already underway, WordPress site owners need to act fast.

• Update to version 7.1.4: This is the only complete fix for the vulnerability.
• Logs for any suspicious activity should be searched: It is recommended that you look for suspicious requests to PHP files within wp-content/upgrade folder.
• Audit of the administrator accounts should be performed: Search for new administrator accounts created because of an attack on your site.
• Plugins and PHP files should be reviewed: Search for any new plugins or PHP files that were not installed by you.
• Staging directory should be hardened: It is possible to limit access to wp-content/upgrade folder although the update to 7.1.4 is the main solution.

FAQ

What is the WordPress Core vulnerability?

It is a remote code execution flaw in WordPress Core versions 4.7 through 7.1.3. It exploits the predictable staging directory (wp-content/upgrade) that WordPress uses during full-package core upgrades.

Is there any CVE number related to this vulnerability?

No. Up to now, there is no CVE number associated with this WordPress Core vulnerability.

How are attackers exploiting this?

They are exploiting a race condition. When WordPress unpacks an update, it leaves the installer files in a web-accessible directory for a few seconds. Attackers poll setup-config.php repeatedly, hoping to hit that brief window and execute code.

Has this been exploited in the wild?

Yes. Wordfence blocked 62,969 attacks targeting the vulnerability in just 24 hours. Two of the largest sources polled small groups of sites for roughly 14.5 hours.

How do I fix it?

Update to WordPress 7.1.4 immediately. Once you have updated, verify your logs for any requests to wp-content/upgrade and perform an account audit on your admin accounts.

Source: The Hacker News