Unauthenticated local PHP file inclusion in WordPress Core can enable conditional RCE

An unauthenticated attacker can make get_page_template() page-template resolution include a chosen readable local .php file outside the active theme directories. If relevant pre-conditions for both the server and the active theme are met, this can lead to RCE.

The structured affected data uses default_status of unaffected and marks versions below the primary fixed release as affected. The WordPress advisory provides these branch-specific boundaries:

• WordPress 7.1 branch: 7.1.0 through 7.1.1 affected; fixed in 7.1.2.
• WordPress 7.0 branch: 7.0.0 through 7.0.5 affected; fixed in 7.0.6.
• WordPress 6.9 through 6.0 branches: 6.9.0 through 6.9.8 fixed in 6.9.9; 6.8.0 through 6.8.9 fixed in 6.8.10; 6.7.0 through 6.7.8 fixed in 6.7.9; 6.6.0 through 6.6.8 fixed in 6.6.9; 6.5.0 through 6.5.11 fixed in 6.5.12; 6.4.0 through 6.4.11 fixed in 6.4.12; 6.3.0 through 6.3.11 fixed in 6.3.12; 6.2.0 through 6.2.12 fixed in 6.2.13; 6.1.0 through 6.1.13 fixed in 6.1.14; 6.0.0 through 6.0.15 fixed in 6.0.16.
• WordPress 5.9 through 5.0 branches: 5.9.0 through 5.9.17 fixed in 5.9.18; 5.8.0 through 5.8.16 fixed in 5.8.17; 5.7.0 through 5.7.18 fixed in 5.7.19; 5.6.0 through 5.6.20 fixed in 5.6.21; 5.5.0 through 5.5.21 fixed in 5.5.22; 5.4.0 through 5.4.22 fixed in 5.4.23; 5.3.0 through 5.3.24 fixed in 5.3.25; 5.2.0 through 5.2.27 fixed in 5.2.28; 5.1.0 through 5.1.25 fixed in 5.1.26; 5.0.0 through 5.0.28 fixed in 5.0.29.
• WordPress 4.9 through 4.7 branches: 4.9.0 through 4.9.32 fixed in 4.9.33; 4.8.0 through 4.8.31 fixed in 4.8.32; 4.7.0 through 4.7.36 fixed in 4.7.37. No status for a parallel or otherwise unsupported branch should be inferred beyond these documented boundaries.

The vulnerable component is page-template resolution in get_page_template() within wp-includes/template.php. According to the vendor advisory and research material, attacker-controlled pagename data can survive sanitization in encoded form and be decoded while WordPress constructs a template candidate, allowing path traversal outside active theme directories when containment checks are insufficient. The active child or parent theme must contain a top-level directory whose name begins with page-. The target must be a local .php file that exists on the server and is readable by the web-server account. The documented RCE chain uses PEAR's pearcmd.php and requires register_argc_argv to be enabled; the advisory specifically calls out the official PHP Docker image and certain default cPanel configurations as examples with the relevant conditions. The available evidence does not establish how common these conditions are across all themes, server layouts, or target files, and local file inclusion may exist without the RCE prerequisites.

• The vulnerability is reachable over the network and requires no authentication.
• No user interaction is required.
• Exploitation has high complexity because multiple WordPress theme and server conditions must be met.
• The supplied record marks the vulnerability as known exploited and having a public exploit. Patchstack reported active exploitation, including probing for file inclusion and attempts to use pearcmd.php to write PHP files.
• Public scanning tooling for the vulnerability has been observed in attack traffic. Not every WordPress installation has been shown to reach RCE.

Successful exploitation allows WordPress to include a chosen local PHP file outside the active theme directories. This can expose data or affect processing depending on the target file and the web server's read permissions. When pearcmd.php is available, register_argc_argv is enabled, and the other relevant conditions are present, the documented chain can turn the inclusion primitive into PHP file writing and code execution with the web-server account's privileges. Organisational consequences may include modification of content or configuration accessible to that account, access to available server data, and service disruption. The evidence does not establish privilege escalation beyond the web-server account or impact to connected systems.

Successful inclusion can expose or affect the processing of local PHP files readable by the web-server account. When the PEAR chain prerequisites are present, an attacker may write attacker-controlled PHP files and execute code with the web-server account's privileges, creating risks to integrity, accessible data, and service availability. The practical impact is bounded by that account's permissions; the available evidence does not establish escalation to the entire host. Because active exploitation has been reported, unpatched systems should receive both update and incident review.

1. Update WordPress Core to the branch-matched fixed release: 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32, or 4.7.37. Do not substitute a fixed release from one branch for an assumption that another branch is also fixed.
2. If updating is temporarily delayed, verify the exposure conditions, including whether the active child or parent theme contains a top-level directory beginning with page- and whether PHP has register_argc_argv enabled. Disabling register_argc_argv may remove the condition required for the documented PEAR-to-RCE transition, but it does not fix local file inclusion and is not a replacement for updating.
3. Review access logs, error logs, and the filesystem using the checks in detection, especially for encoded traversal requests, pearcmd access, and unexpected PHP files in /tmp or /var/tmp.
4. If there is evidence that inclusion executed or that a suspicious request wrote a PHP file, treat the system as potentially compromised and follow appropriate investigation, isolation, and recovery procedures based on the web-server account's access.

1. Inventory the installed WordPress version and branch, then compare them with the affected and fixed boundaries in affected_summary; do not infer safety merely because another branch has been patched.
2. Inspect the active child and parent themes for a top-level directory beginning with page-. This is an exposure precondition identified by the advisory, not by itself proof that exploitation occurred.
3. Review PHP configuration for register_argc_argv, and check whether pearcmd.php exists and is readable when assessing the documented RCE chain.
4. In access logs, search for pagename values containing encoded traversal such as %2e%2e or %252e%252e, prefixes such as templates%2f or another page- directory name, especially when paired with page_id at the site root or /index.php, in both query strings and POST bodies.
5. Search for pearcmd, +config-show, and +config-create, as well as the user agents cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0. These are observed indicators, but user agents can be spoofed.
6. Inspect /tmp and /var/tmp for unexpected .php files. Such files can indicate that the file-writing stage succeeded and should be treated as evidence of possible compromise. OPML or RSS output returned from an ordinary page URL can also indicate that inclusion executed; absence of these signs does not prove the host is safe.