Start a Pentest Book a Demo
  • Blog
  • AI Penetration Testing

CVE-2026-87902: From WordPress path traversal to RCE via PEAR

Edoardo Zatti, Zoran Gorgiev
Table of contents
CVE-2026-87902: From WordPress path traversal to RCE via PEAR

WordPress has released version 7.1.2 to fix a pre-authentication path traversal in its core. This vulnerability is tracked as CVE-2026-87902 and has a CVSS v4.0 score of 9.2 (Critical). Exploiting it does not require authentication or a vulnerable plugin. It was discovered and responsibly disclosed by security researcher Robert Ressl.

Every WordPress release from 4.7.0 through 7.1.1 is affected, which amounts to roughly a decade of releases. A verified, runnable proof of concept demonstrating exploitation of the vulnerability is already public.

Although exploitation depends on additional theme and server-side conditions, vulnerable deployments should still be treated as a priority. Where those conditions are present, this security flaw can allow unauthenticated local PHP inclusion and, in some environments, lead to remote code execution.

A version check alone cannot tell you whether those conditions are present in your deployment. Equixly can test whether the vulnerable path is reachable in your environment.

What is CVE-2026-87902?

In wp-includes/template.php, get_page_template() reads the pagename query variable and applies urldecode() to it. It then uses the decoded value to build a candidate template name. In vulnerable releases, WordPress validates the custom page template with validate_file(), but it does not apply the same check to the candidate derived from pagename.

The traversal works through the following sequence:

  1. An attacker sends a double-encoded traversal sequence through pagename.
  2. The sequence passes through WordPress’s earlier sanitization without losing the encoded traversal characters.
  3. get_page_template() applies urldecode(), which turns the value into a traversal path.
  4. WordPress uses the decoded value to build a template name in the form page-{decoded}.php.
  5. locate_template() resolves that path to a readable .php file outside the theme directories.
  6. The template loader includes the file.

The attacker also includes a valid page_id in the same request. This action keeps WordPress on a real published page and allows the request to reach template resolution with the malicious pagename value still available.

The published reproduction uses an anonymous POST request, rather than GET, to trigger the vulnerable template resolution flow.

Which WordPress versions does CVE-2026-87902 affect?

Branch Last vulnerable Fixed release
7.1.x 7.1.1 7.1.2
7.0.x 7.0.5 7.0.6
6.9.x 6.9.8 6.9.9
6.8.x 6.8.9 6.8.10
6.7.x 6.7.8 6.7.9
4.7.0 to 6.6.x 6.6.8 6.6.9, with backports down to 4.7.37
Earlier than 4.7.0 n/a Not affected

What is the impact of CVE-2026-87902?

CVE-2026-87902 can have two different outcomes, depending on the WordPress theme and the underlying server configuration.

Outcome 1: Local PHP file inclusion

An unauthenticated attacker can make WordPress include and execute a readable local .php file located outside the active theme directories. However, this does not apply to every unpatched WordPress installation.

The active child or parent theme must contain a usable top-level directory whose name starts with page-. This requirement exists because WordPress prepends page- to the portion of the template path controlled by the attacker during template resolution.

WordPress identifies Twenty Twelve and Twenty Fourteen, along with third-party themes including Neve, Hestia, and Sydney, as examples that meet this theme requirement.

The published proof of concept also depends on several practical conditions:

  • WordPress must have a published page that the attacker can reference with a valid page_id.
  • No other template can take priority before WordPress reaches the vulnerable template candidate.
  • The attacker must be able to target a readable local PHP file.
  • The server must allow WordPress to access that file.

When these conditions are met, an unauthenticated attacker can use the vulnerability to make WordPress load and execute a readable local PHP file outside the theme directories.

Outcome 2: Remote code execution

Remote code execution requires additional server-side conditions. In the documented exploit chain, the attacker uses a local PHP file to turn the file inclusion into code execution.

The attacker uses PEAR’s /usr/local/lib/php/pearcmd.php. WordPress notes that this escalation path can work when register_argc_argv=On, including in affected official PHP Docker environments.

The public proof of concept demonstrates the chain with a pinned wordpress:7.0.2-php8.3-apache environment. Its lab also adds a page-templates/ directory to Twenty Twenty-Five and explicitly enables register_argc_argv. These changes provide the required theme and PHP conditions.

In the tested upstream runtime, PHP loads no main php.ini, so the compiled default leaves register_argc_argv=On. Production php.ini configurations commonly set this option to Off. That means operators need to verify the setting in their own environment rather than assume that the PEAR escalation path is available.

In the demonstrated exploit, the attacker first reaches pearcmd.php and uses it to write attacker-controlled PHP to a writable location such as /tmp. A second request then exploits the WordPress file inclusion vulnerability again to load that file and execute the injected PHP with the privileges of the web server user.

The official PHP-based WordPress image can therefore provide some of the server-side conditions needed for the PEAR escalation. However, a stock deployment does not automatically satisfy the complete exploit chain.

The key distinction is that local PHP file inclusion is the core vulnerability. Remote code execution is a possible consequence when the theme, PHP runtime, and filesystem configuration provide the additional conditions the attacker needs.

How to test whether you’re vulnerable to CVE-2026-87902

Checking your WordPress version tells you if you are running an affected release. It does not tell you whether an attacker can exploit CVE-2026-87902 under the conditions present in your deployment.

Equixly tests your WordPress environment for CVE-2026-87902 to answer two questions:

  • Is the vulnerable path reachable?
  • Can exploitation progress beyond local PHP inclusion under the application and server conditions in place?

After you patch or apply mitigations, run the test again to verify the effect of those changes. If the retest shows the vulnerable path is still reachable, confirm that the fixed release is running in the deployed environment and, where you applied mitigations only, prioritize patching.

CVE-2026-87902 indicators of compromise and exploitation attempts

The attack must pass an encoded traversal sequence through pagename, which gives defenders a useful place to start. The surrounding indicators can vary between exploit chains, so these should be treated as leads rather than a clean bill of health:

  • Requests carrying both page_id and pagename, particularly POST requests, where pagename contains %25 sequences or decodes into traversal components such as ../.
  • Query strings containing PEAR command syntax such as +config-create+, or raw PHP opening sequences such as <?, on requests to the WordPress front end. However, note that these are indicators of the published PEAR escalation chain, not of every possible CVE-2026-87902 exploit.
  • pearcmd.php, or another out-of-theme .php file, reached through WordPress template loading.
  • New or unexpected PHP files in writable locations, including temporary directories such as /tmp, the web root, or wp-content.
  • Unexpected child processes or outbound connections originating from the web server process.

CVE-2026-87902 mitigation, remediation, and detection in WordPress

The following recommendations can help reduce exposure, confirm remediation, and identify signs of compromise:

  • Verify the WordPress version you are running through WP-CLI, your hosting platform, or the deployed container image. Do not rely only on the version expected by your deployment configuration.
  • Patch to WordPress 7.1.2, or the fixed security release for your branch: 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, and the corresponding backports through 4.7.37.
  • If you cannot patch immediately, review the PHP environment. Setting register_argc_argv=Off for web SAPIs and removing PEAR from images exposed to web traffic disrupts the documented route from file inclusion to RCE using PEAR. It does not, however, fix the underlying WordPress inclusion flaw or rule out other escalation paths specific to your environment.
  • Review active child and parent themes for page-* directories at the top level of the theme. Twenty Twelve, Twenty Fourteen, Neve, Hestia, and Sydney are among the examples identified by WordPress as satisfying this requirement.
  • Review filesystem access and runtime confinement. Controls such as open_basedir or mandatory access control policies can block parts of the demonstrated chain. A noexec mount on /tmp alone does not prevent the demonstrated behavior because PHP reads and interprets the generated file rather than asking the operating system to execute it directly.
  • Validate exposure in your environment. Confirm the deployed WordPress version and relevant configuration, determine whether CVE-2026-87902 can be turned into a working attack path, and retest after remediation or mitigation to verify the effect of those changes. Equixly can run this validation against your deployed environment.
  • Check logs for signs of attempted or successful exploitation before relevant data falls outside your retention period. Since pagename can arrive in a POST body, standard web access logs may not contain the traversal value. Look for anomalous POST requests to WordPress front-end URLs and PEAR command syntax in access logs. Also inspect WAF, reverse proxy, and application logs for pagename values encoded twice where request bodies are retained.
  • Inspect writable directories and the affected runtime for unexpected PHP files, modified files, or other artifacts created by the web server user. Also investigate unexpected child processes or outbound connections originating from the web server process.
  • If you find evidence of successful code execution, treat the affected system as potentially compromised beyond WordPress itself. Investigate the web server or container environment according to your incident response process instead of assuming the impact is limited to a WordPress account.

CVE-2026-87902 risk depends on your WordPress environment

CVE-2026-87902 shows why the presence of a vulnerability does not, by itself, define its practical impact.

The underlying flaw is local PHP inclusion, but what an attacker can do with it depends on the environment WordPress runs in. Theme structure, PHP configuration, and filesystem access can determine whether the issue remains limited to file inclusion or can be extended to remote code execution. The same vulnerable WordPress version can therefore expose different levels of risk across different deployments.

That does not reduce the urgency of patching. It does, however, affect how defenders assess exposure: knowing that a vulnerable version is present does not tell you how far an attacker can take the flaw in that environment.

Book a demo with Equixly to test whether CVE-2026-87902 is exploitable in your environment.

Edoardo Zatti

Edoardo Zatti

Technical Product Manager

With a master's degree in Theoretical Physics, Edoardo has established a robust analytical thinking and problem-solving foundation. During the final year of his studies, he taught an integration course at the university, refining his communication skills and kindling his passion for education. His academic journey took an exciting turn during his master's program as he ventured into the field of computer science through relevant courses. These courses sparked his interest in IT and led him to specialize in backend development, where he sharpened his skills through involvement in complex projects and practical experience in other Tech companies.

Zoran Gorgiev

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.