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):

Preconditions

The standalone inclusion primitive needs:

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

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:

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):

The proof artifact is /flag, root-owned and world-readable (root:root, mode 0444) inside the container. It proves PHP execution and file access as the web-server account; it is not a privilege-escalation target.

How the chain works

Two anonymous POSTs. WordPress routing values travel in the form body, the PEAR arguments in the raw query string (PHP splits the raw query string on literal + into argv and does not URL-decode the individual arguments):

Stage 1 — include pearcmd.php and write the payload:

Stage 2 — include the generated file and run its PHP:

Details that matter:

• Two encoding layers. The body is decoded once by PHP into templates%2f%2e%2e%2f...; the sanitizer keeps those octets, and only get_page_template()'s late urldecode() turns them into / and ...
• page- prefix. WordPress prepends page- to the value, so the fixture directory page-templates/ corresponds to the leading templates segment.
• Forced .php suffix. The candidate is page-<decoded>.php, which is why the target is given without a suffix (.../pearcmd, /tmp/wp-pear-rce-flag).
• POST, not GET. redirect_canonical() skips non-GET/HEAD requests, and the form body lets the query string carry only the PEAR arguments.
• Quote-free payload. wp_magic_quotes() also runs over $_SERVER, so the server-built argv is escaped and PEAR later normalizes the backslashes. The verified payload uses chr() and contains no quote characters. (It reduces to <?=file_get_contents('/flag')?>.)
• config-create root path. PEAR rejects a relative root (Root directory must be an absolute path beginning with "/"), so the payload is injected as the root path itself.
• Depth. cve-2026-87902.py walks .. segments until the traversal reaches the target (7 for the layout of this lab, --depth to pin it).

Lab

lab/up.sh performs three steps and is safe to re-run:

1. docker compose up -d --build --wait — pinned wordpress:7.0.2-php8.3-apache plus mysql:8.4, port 127.0.0.1:8091 (loopback only).
2. Runs the WordPress installer (admin / adminadmin) if the site is not installed yet.
3. Creates the fixture inside the active theme and prints it: wp-content/themes/twentytwentyfive/page-templates/, root:root, mode 0755, empty.

The lab image adds register_argc_argv=On explicitly (lab/Dockerfile) instead of relying on the compiled default, and bakes in /flag (root:root, mode 0444, content CVE-2026-87902-POC-OK).

The rolling wordpress:php8.3-apache tag is not usable for this lab: the bug is fixed in 7.1.2 and an unpinned tag silently turns the lab patched.

Negative controls and limitations

Verified or documented controls:

• No top-level page-* directory in the theme → the fixed prefix cannot be removed and the traversal never starts (verified: fixture removed → no marker).
• register_argc_argv=Off → no PEAR writer, but the inclusion primitive remains.
• PEAR or its dependencies absent → no writer.
• Wrong number of .. segments → target not reached (verified: depths 1-6 and 8-12 produce no marker in the lab).
• A custom page template assigned to the Page → ordered before the malicious candidate and wins.
• An unsuffixed file (e.g. /flag) cannot be read directly — the candidate gets .php appended.
• A WAF/CDN/reverse proxy that rejects raw <, >, = bytes in the request target breaks the PEAR argument channel (deployment-specific).
• open_basedir/MAC confinement or a non-writable output directory breaks the chain; noexec on /tmp does not (PHP reads and interprets the file).

This PoC reproduces one verified configuration. It does not claim that every WordPress installation is exploitable, and it does not measure prevalence.

Remediation

• Upgrade to WordPress 7.1.2 or newer (or to the backport of your branch).
• Defense in depth for template handling: after decoding, reject traversal and absolute candidates (e.g. validate_file()), and before including a located template, compare realpath() of candidate and theme root with a trailing directory separator.
• Operator mitigations: set register_argc_argv=Off for web SAPIs, remove unused web-readable PEAR entry points from production images, audit child and parent themes for top-level page-* directories, and restrict write access for the PHP account.

Files

Disclosure timeline

The report was accepted as a valid security finding after its initial classification was revised; the correspondence does not date that acceptance.

Disclaimer

This repository is published for defensive and research purposes. Use it only against systems you own or are explicitly authorized to test. The lab is bound to 127.0.0.1 and must not be exposed to untrusted networks.

License

MIT — see LICENSE. Citation metadata lives in CITATION.cff:

Ressl, Robert (2026). CVE-2026-87902 PoC: unauthenticated path traversal in WordPress page-template resolution (v1.0.0). https://ressl.ch

The vulnerability report and this PoC were prepared with AI assistance for organization and consistency review; the researcher is responsible for the technical claims.