CVE-2026-87902 — WordPress Core: unauthenticated path traversal in page-template resolution

Unauthenticated local PHP file inclusion in WordPress Core via a double-encoded pagename value — and, under specific deployment conditions, PHP code execution with the web-server account's privileges.

CVE	CVE-2026-87902
Vendor advisory	GHSA-7hp8-65ch-5whp
Write-up	CVE-2026-87902: Critical WordPress file inclusion and conditional RCE
Affected	WordPress Core 4.7.0 – 7.1.1 (every branch, per the advisory's per-branch ranges); reproduced dynamically on 7.0.2
Fixed	7.1.2 (7.1 branch), 7.0.6 (7.0 branch) and a backport for every branch down to 4.7.37 (per the advisory)
Weaknesses	CWE-98 (improper control of filename in include), CWE-22 / CWE-23 (path traversal)
CVSS v3.1	CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — 8.1 High
CVSS v4.0 (supplemental)	CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N — 9.2 Critical
Authentication	none — no account, cookie, nonce, session, plugin, or outbound request
User interaction	none
Author	Robert Ressl — ressl.ch
PoC verified	2026-09-22 against the lab in this repository — see Verified results

Summary

WordPress resolves a Page template through a chain that never proves the selected file stays inside a theme root:

1. pagename and page_id are public query variables that WP::parse_request() accepts from an anonymous POST body.
2. A double-encoded traversal in pagename survives the early query sanitization as escaped %xx octets (wp_basename() cannot see %2f as a separator, and sanitize_title_with_dashes() deliberately keeps valid octets).
3. A valid page_id then selects a real published Page, while the malicious pagename remains in the query object.
4. get_page_template() later calls urldecode() on that value and adds a candidate such as page-templates/../../../../../../../usr/local/lib/php/pearcmd.php to the template hierarchy.
5. locate_template() and the final template loader only check existence, readability and the .php/.html suffix — never that the canonical path is still inside an allowed theme root — and then include it.

That is an unauthenticated remote local-file-inclusion primitive in WordPress Core. On the tested official runtime (wordpress:php8.3-apache, which bundles PEAR and loads no php.ini, so register_argc_argv is On), the inclusion was chained through PEAR's pearcmd.php: a first anonymous request makes config-create write attacker-controlled PHP into /tmp, a second anonymous request includes that file and executes it as www-data.

The missing path containment in Core is the vulnerability. PEAR is only one environment-dependent route from inclusion to code execution — it is not a WordPress dependency and is not present or usable in every deployment.

Root cause

Verified source locations (WordPress 7.0.2):

#	Location	Role
1	wp-includes/class-wp.php:18,322-330	pagename and page_id are public query vars and are read from $_POST
2	wp-includes/class-wp-query.php:2205	sanitize_title_for_query( wp_basename( $query_vars['pagename'] ) ) — %2f is not a separator to wp_basename()
3	wp-includes/formatting.php:2283-2289	sanitize_title_with_dashes() preserves valid %xx octets instead of removing them
4	wp-includes/template.php:492	$pagename_decoded = urldecode( $pagename ); — the traversal becomes active after sanitization
5	wp-includes/template.php:722-736	locate_template() concatenates the candidate below each theme root and only calls file_exists()
6	wp-includes/template-loader.php:116-132	realpath() normalizes the path, then include runs with no canonical root-containment check
7	wp-includes/canonical.php:42-47	redirect_canonical() returns early for non-GET/HEAD, so a POST is not canonicalized away

Preconditions

The standalone inclusion primitive needs:

#	Precondition	Reason
1	A published, anonymously reachable Page selected by numeric page_id	the page must be returned by the query after the pathname lookup fails
2	No earlier resolvable custom page template	a valid assigned template is ordered before the malicious candidate
3	A top-level directory in the active (child or parent) theme whose name starts with page-, e.g. page-templates/	WordPress prepends the fixed page- prefix, so a .. traversal cannot start at position 0; the directory only has to exist and be traversable — it does not have to be writable
4	A selected local .php file that exists and is readable by the PHP user	the loader checks is_file()/is_readable() and requires a .php suffix
5	No filesystem confinement blocking that file	an open_basedir or MAC policy can prevent the include

The demonstrated PEAR stage additionally needs a readable pearcmd.php (plus its dependencies), register_argc_argv=On for the web SAPI, and a writable output directory. Production php.ini files set register_argc_argv=Off; the tested image loads no php.ini, so the compiled default (On) applied. This is an important limit on the prevalence of the demonstrated code-execution chain.

The bundled Twenty Twenty-Three/Four/Five themes ship no top-level page-* directory, so the stock lab needs the fixture described below. Custom themes can legitimately use a page-templates/ layout (WordPress documentation).

The advisory records where these conditions occur in shipped software: the theme condition is met by the legacy Twenty Twelve and Twenty Fourteen themes and by third-party themes such as Neve, Hestia and Sydney, while the PEAR transition applies to the official PHP Docker image and to default cPanel configurations running PHP older than 8.5. (Twenty Twelve and Twenty Fourteen both ship a top-level page-templates/ directory; the remaining statements are the advisory's.) This repository does not measure how often the full chain applies.

Quick start

./lab/up.sh            # WordPress 7.0.2 + MySQL 8.4 + the page-* fixture, installed and ready
python3 cve-2026-87902.py   # two anonymous POSTs, prints the proof marker

cve-2026-87902.py needs Python 3.6+ (standard library only) and reaches the lab at http://127.0.0.1:8091 by default. Expected output:

[*] target        : http://127.0.0.1:8091
[*] page id       : 2 (sample-page, default template, via /index.php?rest_route=/wp/v2/pages&per_page=100&_fields=id,slug,template)
[*] depth 7       : stage 1 HTTP 200, stage 2 HTTP 200
[+] traversal     : page-templates/../../../../../../../usr/local/lib/php/pearcmd.php
[+] payload file  : page-templates/../../../../../../../tmp/wp-pear-rce-flag.php (written by PEAR in stage 1)
[+] marker        : 'CVE-2026-87902-POC-OK' found 12 time(s) in the stage-2 response
[+] proof         : CVE-2026-87902-POC-OK
[+] EXPLOIT SUCCESSFUL - PHP executed with the web-server account's privileges

Exit code is 0 on success and 1 otherwise, so the PoC also works as a regression/detection check.

Teardown: docker compose down -v.

Verified results

Run on 2026-09-22 against this lab (Docker 29.4, OrbStack, Apple silicon):