On September 22, 2026, WordPress shipped version 7.1.2 to fix CVE-2026-87902, a critical local file inclusion flaw in the page-template resolution engine. Less than twelve hours later, the first exploitation attempts were already logged. Five days on, a CrowdSec report puts the scanning volume at more than 30,000 distinct IP addresses, a pace that confirms the patch alone is not enough to keep sites safe.
An unauthenticated flaw at the core of WordPress
Classified as CWE-98 (improper control of filename for include/require) and rated 9.2 under CVSS 4.0 by WordPress.org, CVE-2026-87902 lets an unauthenticated attacker manipulate page-template resolution to force the inclusion of a local PHP file located outside the active theme’s directories. Depending on server configuration, this local file inclusion can escalate to remote code execution. Every WordPress release from 4.7.0 through 7.1.1 is affected.
Timeline of a fast-moving exploitation
| Date | Event |
|---|---|
| September 22, morning | WordPress 7.1.2 released, with backports down to the 4.7.37 branch |
| September 22, 11:49 UTC | First exploitation attempt logged by Patchstack, the same day as the patch |
| September 24 | Active exploitation confirmed in the wild |
| September 23-27 | 30,813 unique IP addresses sent malicious requests, per CrowdSec |
CrowdSec’s report places most of the scanning volume in the United States (22%) and Iran (20%), followed by Lithuania, the Netherlands, and France. This country breakdown reflects the origin of the requests, not the attackers’ nationality: most of these addresses belong to already-compromised servers or devices used as relays.
Some administrators deliberately disable WordPress’s automatic updates, which puts them on the front line for the entire patching window.
Why automatic updates are not always enough
WordPress has shipped critical fixes through automatic minor updates for years, but that protection depends on a setting many hosts and agencies turn off to keep control over deployment. Staging environments, container instances, and preproduction copies often fall outside that mechanism and stay vulnerable longer than the production site they are meant to mirror — a real concern for anyone running a self-hosted WordPress setup with several active copies.
Virtual patching through a web application firewall (CrowdSec AppSec or an equivalent hosting-provider tool) does not replace the update: it buys time while the fix rolls out across the whole fleet, staging included.
Hardening the PHP configuration as a second layer
Beyond upgrading to 7.1.2 or a patched branch, recommendations also point to the server’s PHP configuration, in particular the register_argc_argv directive and the presence of the pearcmd.php script, two elements that make file-inclusion flaws easier to exploit on a poorly hardened setup.
; php.ini — reduce the attack surface for file inclusion
register_argc_argv = Off
disable_functions = exec,shell_exec,system,passthru,proc_open
allow_url_include = Off
This baseline lines up with the principles already covered in a minimal WordPress hardening baseline: limit what PHP can execute, separate environments, and confirm the patched version is actually the one running, staging copies included.
Key takeaways
CVE-2026-87902 sits at the core of WordPress, requires no authentication, and is under heavy, active scanning since disclosure. Upgrading to 7.1.2 or a patched branch is the priority, and it needs checking on every environment — production, staging, containers — not just the publicly visible site.
Flaws like this one are why I consistently recommend treating staging copies as targets in their own right: it is often the preproduction instance, left out of automatic updates, that ends up as the entry point into the infrastructure hosting the public site. — Simon Janvier
Further reading: the full CrowdSec report on the exploitation of CVE-2026-87902 is available at crowdsec.net.
