Four hours. That’s roughly how long it took attackers to go from probing a freshly patched WordPress flaw to actually writing files onto compromised servers. WordPress shipped its second security release in five days on September 22, fixing an unauthenticated path traversal bug in how the platform resolves page templates, and exploitation started before the day was even over.
Patchstack recorded the first attack attempt at 11:49 UTC that same day. By 15:34 UTC, attackers were writing files to disk. A public scanning template was circulating within 24 hours, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 25, giving federal agencies until September 28 to patch.
The bug comes down to something deceptively simple: a missing validation check. When WordPress decides what to render, it builds template filenames from two inputs. One goes through the platform’s own traversal protection. The other never did. That oversight opened a door for unauthenticated requests to pull in any readable PHP file sitting outside the active theme.
On its own, that is a problem, but a contained one. Add two host-side conditions, a PHP setting called register_argc_argv and the presence of PEAR’s pearcmd.php, and it becomes remote code execution. Patchstack found that combination showing up far more often than anyone would like. The PHP setting turns on by default in official PHP Docker images and in cPanel environments running PHP below version 8.5, which puts a lot of real-world servers in range.
CrowdSec’s telemetry shows the exploit spreading fast. Distinct attacking sources jumped from 237 on the first day to over 23,000 by September 27, while requests per source actually dropped, a pattern researchers associate with an exploit moving from a handful of skilled operators into automated, commodity scanning tools anyone can point at a target list.
WordPress didn’t just patch the one bug, either. Alongside the specific fix, the security team added a broader check requiring every resolved template path to stay inside approved directories, treating template resolution as a category of risk rather than a single isolated flaw.
For site owners who cannot update right away, two quick checks are worth running: whether the active theme has a directory starting with “page-,” and whether register_argc_argv is currently on. Pulling out PEAR where it serves no purpose closes the known path to code execution without touching a single WordPress installation in the process.
