WordPress Core Patched in Hours. Attackers Were Already Inside.

At 11:49 UTC on September 22, 2026, the first probe hit, occurring five hours and forty-nine minutes after WordPress 7.1.2 shipped . This rapid transition from patch release to active exploitation confirms the persistent patch-gap pattern, where the disclosure of a vulnerability functions as a roadmap for attackers rather than a defensive window for administrators.

The vulnerability, a CVSS 9.2 critical flaw discovered by Robert Ressl, resides in the page-template resolution logic of WordPress versions 4.7.0 through 7.1.1. The root cause involves double-encoded directory traversal sequences—specifically %252e%252e, which decodes to ../. When processed by the urldecode() function within get_page_template(), these sequences bypass the standard slug sanitizer. This allows the locate_template() function to resolve and include PHP files located outside the intended theme directory.

Exploitation follows a precise three-stage chain. Attackers first perform reconnaissance by probing core files like wp-links-opml.php to confirm the vulnerability is live. They then verify the reachability of pearcmd.php, a common PEAR component , by invoking +config-show. Finally, they leverage config-create to write arbitrary PHP files to system directories such as /tmp or /var/tmp. This execution path is conditional: it requires a theme containing a page-* directory and a server configuration where pearcmd.php is readable and register_argc_argv is set to On. These conditions are frequently met in default Docker PHP images and cPanel environments running PHP versions below 8.5.

The speed of this campaign stems from the commoditization of the exploit. Publicly available Nuclei templates now automate the detection and exploitation process, allowing attackers to scale their efforts from a small cluster of IPs on the evening of September 22 to hundreds by the following day. This mirrors the BlueMoon Patch-Gap (Post 130558) , which identified that infrastructure-scale software—like WordPress, which powers approximately 40% of the web—is increasingly targeted the moment a patch diff becomes public.

WordPress developers addressed the flaw in version 7.1.2 by implementing a two-layered defense. They added a validate_file() check on the pagename branch and introduced the _wp_is_template_path_allowed() function to block traversal attempts within locate_template(). This defense-in-depth approach aims to secure the broader template system against similar future bypasses.

Patchstack advises: “Treat it as critical unless you have checked your own stack and know otherwise.” For those managing WordPress estates, the reality is that the patch-gap is now a permanent feature of the attack surface.