WordPress Core Flaw Hit by Tens of Thousands of Attacks a Day Right After Patch Release

Translated by a model; the original is in Russian.

· Security
Attackers began going after a remote code execution flaw in WordPress Core soon after it was patched. Wordfence says it blocked nearly 63,000 attempts in 24 hours.

cover.svg

Threat actors are trying to exploit a high-severity flaw in WordPress Core, and the attempts began soon after fixes were released. The bug allows remote code execution on the server and affects WordPress Core versions 4.7 through 7.1.3. It has no CVE identifier and carries a CVSS score of 8.1. Patches were published on October 28, 2026.

What went wrong

According to Wordfence, a company that specializes in WordPress security, the vulnerability stems from predictable, web-accessible staging paths used during full-package Core upgrades. That lets an unauthenticated attacker execute code on the server while an upgrade is in progress.

Affected versions unpack the new files into a predictable directory under wp-content/upgrade, and that copy includes the WordPress installer. "Because the staging directory is web-accessible on many servers, 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," said Alex Thomas, who leads the Wordfence Threat Response Team.

A narrow window

Successful exploitation means winning a race condition, landing a request during the very short period while WordPress is unpacking the update. Several conditions have to line up:

  • a full-package update that contains the installer files;
  • public web and PHP access to the staging tree;
  • a predictable or discovered staging path;
  • enough time to finish the attack before WordPress cleans up the temporary files.

In normal lab environments, that window lasts only seconds. Attackers are not deterred, though, and are repeatedly polling vulnerable paths such as setup-config.php. Over the past 24 hours, Wordfence blocked 62,969 attacks targeting the flaw.

"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 variations of staging-directory and version names. 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 started targeting it.

What to do

WordPress site owners are advised to update to version 7.1.4 as soon as possible. They should also check logs for suspicious requests to PHP files under wp-content/upgrade and look for unfamiliar administrator accounts, plugins, or PHP files.


Source: The Hacker News

Comments

Sign in, to comment.

  • No comments yet.