WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours

The vulnerability affects WordPress Core versions 4.7 through 7.1.3 and has a CVSS score of 8.1. Attackers began probing it shortly after patches were released on October 28, 2026. The flaw is especially serious because it can lead to remote code execution, not merely information exposure or a failed request.

During a full-package Core update, WordPress temporarily unpacks files under a predictable directory in wp-content/upgrade. That staged copy includes the WordPress installer. If an attacker reaches the installer during the brief upgrade window, they can interact with the temporary copy and progress to PHP code execution.

Remote code execution means the attacker’s requests cause the server to run code chosen by the attacker. Exploitation requires precise timing and several conditions, but threat actors are repeatedly polling vulnerable paths to win that race. Site owners should update to version 7.1.4 promptly.

Wordfence reported blocking 62,969 attacks targeting the vulnerability over the 24 hours after observing exploitation attempts. The number shows that this was not a theoretical risk waiting for future research. Threat actors were already directing repeated requests at vulnerable WordPress sites.

The attacks focused on paths such as setup-config.php, which appears in the temporary WordPress copy. Attackers repeatedly polled vulnerable paths because the usable opening may last only seconds in normal laboratory environments. Two major sources polled small groups of sites for about 14.5 hours.

The volume and persistence reveal how quickly attackers understood the race condition. Some sources tested different staging-directory and version-name variations, while others used exact-layout probes. Wordfence’s count does not mean every request succeeded, but it demonstrates sustained exploitation activity soon after patches became available.

A full-package WordPress Core update first unpacks new files into a temporary directory under wp-content/upgrade. That temporary copy includes the WordPress installer. The vulnerability appears because the staging directory can be web-accessible while the update is still being prepared.

An attacker must reach the staged installer at exactly the right moment. The directory path is predictable or discoverable, but the useful files exist only during the upgrade process. After the update finishes, WordPress cleans up the temporary files, removing the brief opportunity.

This creates a race condition between the updater and the attacker. The attacker repeatedly sends requests, hoping to arrive before cleanup. Wordfence observed that the opening lasted only seconds in normal laboratory environments. The narrow timing makes exploitation difficult, but persistent polling allows attackers to keep trying across many updates and sites.

The staging directory can be web-accessible on many servers during a full-package Core update. Because the directory contains a temporary WordPress copy, it also contains installer files that normally help configure WordPress. An unauthenticated attacker can send requests without first signing in.

The attacker repeatedly requests a path such as setup-config.php, using a predictable or discovered staging path. If one request arrives while WordPress is unpacking the update, the attacker can interact with the staged installer. That interaction can progress to PHP code execution in the staged copy.

Success depends on winning the timing race before WordPress cleans up the temporary files. The attacker also needs public web and PHP access to the staging tree. The result can be code execution on the server, which is why the flaw is rated high severity despite its very short exploitation window.

The first requirement is a full-package WordPress Core update containing the installer files. Without that temporary installer copy, the attacker has no staged target to use. The attack also requires the staging tree to be publicly reachable through the web and able to process PHP.

The attacker must know or discover a predictable staging path. They also need enough time to complete the interaction before WordPress deletes the temporary files. This is difficult because the usable window lasted only seconds in normal laboratory environments.

All four conditions described by Wordfence must align: the right update, public web and PHP access, a known staging path, and adequate time. Threat actors try to create that opportunity by repeatedly polling paths and testing directory and version-name variations. Their activity shows that the narrow window is difficult, but not stopping determined attackers.

The clearest protective action is to update WordPress to version 7.1.4 as soon as possible. The article gives this advice because active exploitation attempts were already underway after patches were released. Updating addresses the vulnerable Core versions identified in the report.

After updating, owners should look for suspicious requests to PHP files beneath wp-content/upgrade. That location matters because it is where WordPress stages files during full-package Core upgrades. Repeated or unusual requests may indicate attackers were probing the temporary installer paths.

Owners should also check for unfamiliar administrator accounts, plugins, or PHP files. These signs could reveal suspicious activity connected with an attempted compromise, although the article does not say that every such finding proves exploitation. Monitoring remains important because attackers tested many staging-directory and version-name variations while trying to catch the short upgrade window.

A race condition occurs when the outcome depends on which event happens first. Here, the attacker’s request must arrive before WordPress finishes the upgrade and deletes the temporary files. The attacker therefore repeatedly polls the target, trying to win a very narrow timing window.

A web-accessible directory is a folder that outside users can reach through web requests. During a full-package update, WordPress places a temporary copy under wp-content/upgrade. PHP code execution means the server processes PHP instructions, potentially allowing code sent through the staged installer to run.

These elements reinforce one another. Public access lets an unauthenticated attacker reach the temporary files. The race condition provides a brief opening, and PHP execution turns access into the ability to run code on the server. Wordfence observed active polling, showing that attackers were already attempting to combine these weaknesses.