CVE-2026-87902: Critical WordPress Core Flaw Enables Unauthenticated RCE Under Certain Conditions

WordPress has released an emergency security update addressing a critical vulnerability in its Core software that can allow an unauthenticated attacker to load arbitrary local PHP files and, under specific server and theme conditions, achieve remote code execution. Tracked as CVE-2026-87902, the vulnerability affects WordPress releases from version 4.7.0 through 7.1.1 and carries a CVSS 4.0 score of 9.2.

The flaw resides in WordPress page-template resolution. An attacker can manipulate the value WordPress uses when selecting a page template and cause get_page_template() to include a readable PHP file outside the directories of the active theme. No WordPress account, authentication cookie, administrator interaction, or vulnerable plugin is required for the underlying file-inclusion attack.

Remote code execution is conditional rather than universal. The active theme must contain a compatible directory structure, and the server must expose a suitable readable PHP file that can be abused when included. The publicly demonstrated attack used PEAR’s pearcmd.php in an environment where PHP’s register_argc_argv setting was enabled.

WordPress released version 7.1.2 on September 22, 2026, specifically to address the vulnerability and has backported fixes to maintained security branches as far back as WordPress 4.7. Site administrators are strongly advised to update immediately.

Contact Sales

CVE-2026-87902 analysis

The vulnerability originates in how WordPress Core resolves templates for pages. When a visitor requests a page, WordPress builds a list of potential template filenames and searches the active theme for a matching file.

In vulnerable versions, attacker-controlled data used during this process is not sufficiently constrained before being incorporated into the page-template path. A crafted request can therefore introduce directory traversal sequences and cause WordPress to resolve a PHP file that resides outside the expected active-theme directories.

The key details for CVE-2026-87902 are that the core primitive is local file inclusion, not unconditional arbitrary code execution. WordPress officially describes the issue as allowing an unauthenticated attacker to make page-template resolution include a chosen readable local .php file outside the theme directories. RCE becomes possible only when additional environmental prerequisites are satisfied.

A vulnerable theme must contain a top-level directory whose name begins with page-, such as:

page-templates

WordPress’ advisory identifies legacy Twenty Twelve and Twenty Fourteen themes among those meeting this structural requirement. Popular third-party themes including Neve, Hestia, and Sydney can also contain compatible directory layouts.

A second condition is that the attacker must identify a local PHP file readable by the web-server account that produces useful behavior when included.

Security researcher Robert Ressl demonstrated the RCE path using a PEAR component called pearcmd.php. For that technique to work, PHP’s register_argc_argv option must also be enabled. The official PHP Docker image can meet the relevant conditions, while traditional cPanel configurations using PHP versions before 8.5 may also expose the required environment.

This distinction matters because not every vulnerable WordPress installation is immediately exploitable for arbitrary code execution. A site can contain the vulnerable Core code while lacking the theme structure or PHP environment required by the demonstrated exploit chain.

Nevertheless, the local file-inclusion primitive itself crosses an important security boundary and requires no authentication or user interaction.

CVE-2026-87902 affects WordPress Core from version 4.7.0 through 7.1.1. The official advisory lists vulnerable branches individually, including:

• WordPress 7.1.0–7.1.1
• WordPress 7.0.0–7.0.5
• WordPress 6.9.0–6.9.8
• WordPress 6.8.0–6.8.9
• WordPress 6.7.0–6.7.8
• WordPress 6.6.0–6.6.8
• All corresponding affected branches back through WordPress 4.7.36

WordPress 7.1.1, released only five days earlier as a security update, remains vulnerable to this separate issue.

The vulnerability was discovered by security researcher Robert Ressl and privately reported through WordPress’ HackerOne program on July 20, 2026. WordPress acknowledged the report on July 21 and informed the researcher on September 15 that a fix was planned. The patch and public advisory were released on September 22.

WordPress classifies the vulnerability as Critical with a CVSS 4.0 score of 9.2. Its vector reflects a network-accessible attack with low complexity, no privileges required, and no user interaction, while also recording that additional attack requirements must be present before the maximum demonstrated impact is possible.

A public CVE-2026-87902 PoC was released by the researcher alongside the disclosure. The proof of concept includes a reproducible local laboratory and demonstrates the path from unauthenticated template traversal to local PHP inclusion and conditional RCE. The researcher tested the exploit against WordPress 7.0.2 in isolated environments and did not test it against live production websites.

Successful execution in the demonstrated environment occurred with the privileges of the PHP/web-server account, identified as www-data, rather than automatically providing operating-system root privileges. The practical impact therefore depends partly on the permissions assigned to the web-server process.

An attacker who achieves PHP code execution could potentially deploy a web shell, modify website files, steal WordPress configuration data and database credentials, create persistence, alter content, redirect visitors, or use the compromised site as an initial foothold for additional attacks. These are potential post-exploitation consequences rather than activities currently attributed to a real-world CVE-2026-87902 campaign.

At the time of the original September 22 disclosure, no exploitation in the wild had been reported and CISA’s enrichment record listed exploitation as none.

However, the threat landscape began changing within hours of disclosure. Patchstack reported detecting probing attempts at approximately 17:44 UTC on September 22, less than five hours after WordPress 7.1.2 became available. The observed requests matched the encoding addressed by the patch, suggesting rapid analysis of the security diff.

Importantly, Patchstack characterized the observed traffic as probing rather than successful payload delivery. The requests attempted to include ordinary WordPress Core PHP files and did not demonstrate attacker-controlled code execution. As of September 23, publicly available evidence therefore supports active reconnaissance, but not confirmed successful exploitation in production environments.

There are currently no campaign-specific CVE-2026-87902 IOCs such as malicious domains, file hashes, malware families, or a definitive attacker infrastructure set. Defenders should instead focus on HTTP request patterns associated with abnormal page-template traversal and subsequent filesystem or PHP activity.

Potential warning signs include:

• Requests containing encoded or repeated directory traversal sequences
• Requests attempting to manipulate page-template selection
• Access patterns involving unexpected local PHP filenames
• New PHP files appearing in writable WordPress directories
• Unexpected child processes launched by the PHP or web-server account
• Unexplained outbound connections originating from PHP workers
• New administrator accounts or unauthorized changes to WordPress content
• Modifications to themes, plugins, or Core files after suspicious HTTP requests

Because public exploit information is now available, organizations should expect broader scanning and automated exploit development even though successful real-world compromise has not yet been publicly confirmed.

CVE-2026-87902 Mitigation

The primary remediation is to install a patched WordPress release immediately. WordPress states that the latest branch, WordPress 7.1.2, contains the security fix, and patched releases have also been created for older branches.

The official fixed versions include:

• 7.1 → 7.1.2
• 7.0 → 7.0.6
• 6.9 → 6.9.9
• 6.8 → 6.8.10
• 6.7 → 6.7.9
• 6.6 → 6.6.9
• 6.5 → 6.5.12
• 6.4 → 6.4.12
• 6.3 → 6.3.12
• 6.2 → 6.2.13
• 6.1 → 6.1.14
• 6.0 → 6.0.16

Security backports continue through WordPress 4.7.37. WordPress emphasizes, however, that only the latest WordPress release is actively supported, so upgrading to the current branch is preferable where operationally feasible.

Sites that support automatic background updates should begin receiving the security release automatically. Administrators can verify and manually install the update through:

WordPress Dashboard → Updates → Update Now

WordPress does not provide a complete workaround that replaces installation of the security update.

CVE-2026-87902 detection should begin with identifying all WordPress installations running Core versions 7.1.1 or earlier and then determining whether their active parent or child theme contains a top-level directory beginning with page-.

Administrators should also determine whether PHP is running with:

register_argc_argv = On

and whether readable PEAR components such as pearcmd.php or other potentially useful local PHP entry points exist on the server. These checks help assess exposure to known RCE techniques but do not determine whether the underlying WordPress flaw exists.

To Detect CVE-2026-87902 probing or attempted exploitation, security teams should inspect web-server, WAF, reverse-proxy, PHP, and WordPress telemetry for:

• Encoded ../ or equivalent traversal patterns in frontend requests
• Requests that attempt to manipulate WordPress page-template resolution
• Unusual references to .php files outside active theme directories
• Requests attempting to reach PEAR-related PHP components
• Bursts of similar traversal requests from one source
• PHP workers unexpectedly launching shell commands or system utilities
• New PHP files or web shells appearing after suspicious requests
• Unexpected changes to wp-config.php, themes, plugins, or uploads
• Newly created WordPress administrator accounts
• Suspicious outbound traffic originating from the web server

Patchstack’s observed scanning shows that internet-facing WordPress sites may already receive vulnerability-specific probes, making web and WAF telemetry particularly valuable for retrospective investigation.

Administrators unable to patch immediately can reduce exposure to the demonstrated PEAR-based execution chain by disabling register_argc_argv for web requests when it is not required and removing unused web-readable PEAR components. Robert Ressl stresses that these are hardening measures only; they do not fix the underlying WordPress vulnerability.

Organizations can also reduce potential post-exploitation impact by ensuring the PHP/web-server account follows least-privilege principles. It should not have unnecessary write access to system directories or sensitive application files.

Sites that were internet-accessible before patching should be reviewed for suspicious requests beginning around the September 22 public disclosure, particularly because public PoC material became available at the same time and probing followed within hours.

If suspicious exploitation is identified, administrators should preserve relevant logs and perform a complete integrity review of:

• WordPress Core files
• Active and inactive themes
• Plugins
• The uploads directory
• wp-config.php
• Web-server configuration
• Scheduled tasks and cron entries
• WordPress administrator accounts
• PHP processes and recently created files

Potentially exposed database passwords, API keys, application secrets, or other credentials stored in readable files should be rotated if investigation indicates that an attacker achieved local file inclusion or code execution.

The immediate priority remains updating WordPress itself. Theme changes, disabling PEAR, or modifying PHP settings can reduce particular exploit paths, but they should not be treated as substitutes for the official security release.