WordPress 7.1.2: ThreatShield Protection Already in Place for Critical Unauthenticated LFI-to-RCE Vulnerability

Understanding the WordPress 7.1.2 vulnerability

The flaw, reported by Robert Ressl and rated CVSS 9.2, lives in how WordPress resolves page templates. A value taken directly from the request (the pagename query variable) was used to build a candidate template filename without passing through the same path-traversal validation applied to neighboring code just a few lines away. The result is an unbounded path traversal: an unauthenticated attacker can point template resolution at a readable .php file outside the active theme.

On its own, that's a local file inclusion. It becomes remote code execution when two preconditions line up:

• The active parent or child theme contains a top-level directory whose name begins with page- (for example, page-templates). This includes the legacy Twenty Twelve and Twenty Fourteen themes, as well as popular third-party themes such as Neve, Hestia, and Sydney.
• A readable local .php file exists that is useful when included — most commonly PEAR's pearcmd.php, which becomes exploitable when PHP's register_argc_argv setting is enabled. That configuration is the default in the official PHP Docker images and in cPanel environments running PHP prior to 8.5.

Because these conditions are far more common than "unusual configuration" suggests, this issue should be treated as critical unless you have verified your own stack rules it out. The vulnerability affects WordPress Core from 4.7.0 through 7.1.1 — close to a decade of releases.

ThreatShield protection already in place

As soon as the WordPress Security Team began coordinating this fix with hosts and security partners, Monarx began investigating and building mitigation. Monarx ThreatShield protection has already been deployed for the known ways attackers could exploit this vulnerability.

ThreatShield is Monarx's runtime security layer, designed to detect and block malicious behavior as it happens. When ThreatShield is enabled and set to block, this protection applies automatically without requiring any action from the hosting provider or customer. Environments running in detection mode may surface the activity but will not block it automatically.

WordPress 7.1.2 vulnerability actively exploited in the wild

This vulnerability is not theoretical, it is being actively exploited. As of this writing, ThreatShield has stopped more than 20,000 attempts to exploit CVE-2026-87902 across our protected environments, and that number continues to climb. Exploitation attempts began almost immediately after the release went public, which is exactly the exposure window where unpatched sites are most at risk.

We are actively tracking the following IP addresses probing for and attempting to exploit this vulnerability:

• 92.246.130[.]76
• 24.199.99[.]159
• 209.38.140[.]90
• 79.127.217[.]52
• 187.15.100[.]152
• 187.40.232[.]95
• 169.58.48[.]195

We have also observed the following user-agent strings used in these attempts:

• cve-2026-87902-bulk/1.0
• Mozilla/5.0 (CVE-2026-87902 verified PoC)
• poc/2026.09.22
• Mozilla/5.0 (compatible; SentinelCore-Audit/1.0)

These indicators reflect both automated bulk scanning and targeted proof-of-concept attempts. If you manage your own edge or WAF, blocking these IPs and flagging these user-agents can provide an added layer of defense, though attacker infrastructure and signatures change quickly, which is why runtime protection that keys on malicious behavior rather than static indicators remains the more durable safeguard.

What you need to do now

Whether or not you use ThreatShield, installing the official WordPress security update should remain a priority:

• Update sites to WordPress 7.1.2, or apply the corresponding backported security fix for each affected version as it becomes available (backports down to 4.7 are in progress).
• Alert customers who manage their own installs and encourage them to update promptly.
• Confirm automatic background updates are functioning if you rely on them.

If you already use ThreatShield, make sure it is enabled and set to block — protection for the known exploitation paths has already been deployed automatically.

How ThreatShield helps during the exposure window

Across thousands or even millions of WordPress sites, updating everything the moment a fix ships is rarely realistic. That leaves an exposure window between disclosure and full rollout. ThreatShield is built to cover that window — in this case, customers received protection without having to write or deploy a single rule themselves.

Patching should always come first, but runtime protection provides an additional layer of defense while updates roll out across your infrastructure.

Not yet using ThreatShield? Request a free trial and get automatic runtime protection against emerging WordPress threats like this one — before the next high-severity release lands.

‍

Learn more about ThreatShield and SmartWAF

Read the official WordPress 7.1.2 release announcement

‍

To learn more about how Monarx protects hosting environments from emerging WordPress threats, get in touch with our team.