WordPress Issues Emergency Patch for Critical RCE Vulnerability as Attackers Strike Within Hours of Disclosure

Philip Harris, Research Director at IDC, described the situation as a "textbook example of the new risk reality." He pointed to data from the security firm Patchstack, which began recording attacker activity almost immediately after the patch was made public. "Attackers are exploiting critical bugs within hours of disclosure, and most enterprises are not patching fast enough to keep up," Harris said.

The telemetry provided by Patchstack illustrates a collapsing timeline for vulnerability management. Reconnaissance traffic—attackers probing sites to see if they were running vulnerable versions of WordPress—was detected within five hours of the 7.1.2 release. Within approximately 24 hours, the nature of the traffic shifted from harmless probing to full-scale exploitation attempts.

"The window between disclosure and exploitation has collapsed to the point that the mean time to exploit for critical vulnerabilities is now negative in some cases," Harris observed. "This means exploit code or scanning payloads appear before or immediately after a patch ships. Patchstack recorded the first probing traffic under five hours after the release, and the volume increased roughly tenfold within a day as attackers moved into actual payload delivery."

Aman Mahapatra, chief strategy officer for Tribeca Softech, echoed this sentiment, arguing that the industry needs to rethink how it measures risk. He suggested that the severity of a bug is no longer just about its CVSS score—which in this case is a near-maximum 9.2—but about the speed of the exploit.

"The number that should anchor this story is not the 9.2 CVSS score, but the gap between patch and exploit. With this vulnerability, that gap was effectively zero," Mahapatra said. "WordPress shipped the fix on September 22, and exploitation attempts were blocked the same day using payloads that matched the exact encoding the patch was written to fix. Attackers did not discover this bug through their own independent research; they read the fix. In the modern era, publishing a patch is functionally publishing an exploit guide."

Speedier patching needed

The immediate reaction to such a rapid threat is often a call for universal automated updates. However, for many enterprises, the solution is not that simple. The tension between the need for speed and the need for system stability remains a primary challenge for Chief Information Security Officers (CISOs).

The 2024 CrowdStrike incident, which saw a faulty update cause global IT outages, remains fresh in the minds of many executives. This has led to a renewed hesitancy toward "excessive patch automation." Many enterprise security teams insist on reviewing and testing any system changes in a staging environment before deploying them to production to avoid catastrophic downtime.

Robert Ressl, who discovered the vulnerability, noted that automation also brings a false sense of security if it is not accompanied by rigorous verification. "Having automatic updates enabled is not the same as verifying that the patch is actually installed and functioning," Ressl said in an interview. "Compatibility and availability concerns are legitimate reasons for testing updates, but those tests must happen at an accelerated pace. My recommendation is a rapid, tested rollout with verification across all exposed installations, including staging sites."