Attackers Turn WordPress Template Flaw Into Remote Code Execution Within Hours

A critical flaw in WordPress page-template handling is already being exploited against exposed websites. The vulnerability, tracked as CVE-2026-87902, lets unauthenticated attackers include readable PHP files located outside the active theme directories under specific deployment conditions.

The weakness can be escalated from local file inclusion to remote code execution. Observed attacks use the PEAR utility pearcmd.php to write attacker-controlled PHP content onto vulnerable servers.

Patchstack detected exploitation attempts within hours of public disclosure. The campaign reportedly moved from reconnaissance to active compromises by September 23, after which attack traffic grew to more than ten times its initial volume and spread across many more websites.

Template resolution escapes the active theme directories

CVE-2026-87902 is a path-traversal vulnerability in the logic used by WordPress to select page templates. An external attacker can influence get_page_template() so that it resolves to a chosen, locally readable .php file outside the expected child-theme or parent-theme directories.

The attack does not work against every WordPress installation. Several conditions must align:

• The top-level directory of the active parent or child theme must begin with page-.
• A suitable local PHP file must exist and be readable by the web-server account.
• The vulnerable template-resolution path must be reachable.
• The server and theme must meet additional WordPress preconditions for the inclusion to succeed.

The directory-name requirement explains why theme layout matters. Themes identified as potentially relevant include Twenty Twelve, Twenty Fourteen, Neve, Hestia, and Sydney. Their presence alone does not prove that a site is exploitable; administrators must also evaluate the active directory structure, PHP environment, permissions, and available local files.

The vulnerability has been assigned two different severity records in the available data. SecurityWeek reports a CVSS score of 9.2, citing WordPress and Patchstack. A separate verified record assigns CVSS 8.1 with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

Both assessments reflect potentially severe confidentiality, integrity, and availability consequences. The 8.1 vector also captures the attack’s high complexity: exploitation is unauthenticated and network-accessible, but it depends on multiple environmental conditions.

PEAR provides the bridge from file inclusion to code execution

The attacks observed so far target pearcmd.php, a command-line component associated with PHP’s PEAR package-management system. Its availability can give attackers a route from local PHP file inclusion to command execution.

When PHP’s register_argc_argv option is enabled, request-supplied data can be exposed through argument-related variables. Attackers can combine that behavior with the inclusion of pearcmd.php, abusing the utility to write PHP content to the server. Executing that newly created file completes the RCE chain.

The reported operation follows three stages:

1. Attackers test whether a WordPress installation is vulnerable to the template traversal.
2. They probe for or attempt to include pearcmd.php.
3. If the required conditions are present, they use PEAR functionality to create PHP code and execute it.

This distinction matters during incident response. A request testing template paths may indicate scanning, while successful file creation or subsequent PHP execution signals a likely compromise.

The official PHP Docker image is reported to be affected by the relevant environmental conditions. Default cPanel configurations are also affected when they use PHP versions earlier than 8.5. In both cases, actual exposure still depends on the WordPress theme and server prerequisites.

Public patch analysis appears to have accelerated exploitation

Patchstack assessed that the encoding used in the first payloads closely matched the code change introduced to correct the flaw. That suggests the attackers studied the public patch difference and rapidly converted it into working exploit traffic.

No specific threat actor has been identified. The early requests originated from a small cluster of IP addresses, but no addresses, domains, file hashes, payload samples, or other atomic indicators have been made available.

The initial activity focused mainly on finding vulnerable installations. By September 23, Patchstack was observing active compromises rather than reconnaissance alone. Traffic subsequently exceeded the first evening’s volume by more than tenfold and reached a substantially broader collection of sites.

Public scanning tools are also available, lowering the effort needed to identify installations with potentially vulnerable configurations. Defenders therefore cannot rely on the number of prerequisites to keep the issue obscure.

WordPress 7.1.2 closes the vulnerable path

WordPress fixed the issue in version 7.1.2 and backported the correction to supported branches extending as far back as 4.7.x. The exact version number of every fixed backport is not available.

Administrators should upgrade to WordPress 7.1.2 or install the corrected release for their current branch. Configuration changes can reduce exposure, but they are not substitutes for applying the WordPress patch.

Priority checks should include:

• Identifying active parent and child themes whose top-level directory names begin with page-.
• Reviewing sites using Twenty Twelve, Twenty Fourteen, Neve, Hestia, or Sydney.
• Determining whether pearcmd.php exists and is readable by the web-server account.
• Checking whether register_argc_argv is enabled and disabling or restricting it where operationally possible.
• Auditing permissions on local PHP files, including files outside theme directories.
• Reviewing official PHP Docker deployments and cPanel systems running PHP earlier than 8.5.

Removing PEAR exposure or changing register_argc_argv may disrupt the reported exploitation chain. Those measures do not correct the underlying page-template traversal.

Logs should distinguish scanning from successful compromise

Web-server and WordPress logs should be searched for unusual requests involving page-template traversal, attempts to resolve files outside theme directories, and references to pearcmd.php.

Defenders should also look for the sequence described in the observed campaign: an initial vulnerability test, a PEAR inclusion probe, and a later request executing newly written PHP. Unexpected PHP files warrant immediate investigation, especially when their creation follows suspicious template-resolution requests.

If evidence indicates that the chain reached its final stage, administrators should treat the host as compromised. Response should include preserving relevant logs, isolating the affected system where appropriate, and examining it for:

• Newly written or modified PHP files.
• Web shells or other persistence mechanisms.
• Commands executed with the web-server account’s privileges.
• Access to WordPress secrets or credentials.
• Connections to other internal services.
• Signs of credential theft or lateral movement.

Reinstalling a clean WordPress core alone may not remove files created elsewhere on the host.

CISA KEV status remains unknown

No confirmed CISA Known Exploited Vulnerabilities catalog status or federal remediation deadline is available for CVE-2026-87902. No ransomware-use flag has been reported either.

That missing catalog information does not change the operational evidence: exploitation was observed within hours of disclosure, and active compromises were reported by September 23. Administrators should prioritize patching based on that activity rather than waiting for a KEV listing.