CVE-2026-87902 is a critical (CVSS 9.2, CVSS4 vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H; NVD also lists CVSS 3.1 8.1, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) path-traversal-to-local-file-inclusion vulnerability (CWE-98, Improper Control of Filename for Include/Require in PHP) in WordPress core versions 4.7.0 through 7.1.1, affecting the decade-plus of releases in that range. The root cause is in wp-includes/template.php inside get_page_template(): when WordPress resolves which template to render for a requested page, it builds a candidate filename by concatenating a caller-influenced value onto a fixed 'page-' prefix and '.php' suffix. A neighboring code branch three lines away already applies a validate_file() containment check before using similar input; the pagename branch does not, an inconsistency in security controls across otherwise-similar operations that Robert Ressl (the discoverer) documented in his write-up and PoC.

The practical exploitation path relies on double URL-encoding: WordPress's request sanitizer strips literal '../' sequences but does not recognize percent-encoded octets (e.g. %252e%252e, i.e. '..' encoded twice), so a payload like 'templates%252f%252e%252e%252f...' survives the initial filter. Later, when get_page_template() calls urldecode() on the pagename value, the encoded traversal sequence is converted into real '../' path segments, and locate_template() concatenates the now-decoded value onto the theme path without re-validating containment. template-loader.php then includes whatever file that traversal resolves to, provided it exists and is readable, without confirming the resolved path stays inside an allowed theme directory. WordPress 7.1.2 closes this two ways: it applies validate_file() to the pagename branch to match the sibling branch, and adds a new _wp_is_template_path_allowed() containment check requiring all resolved template paths to remain inside allowed theme directories -- a defense-in-depth response suggesting broader concern about the template-resolution surface generally.

By itself the flaw is 'only' unauthenticated arbitrary local .php file inclusion (an attacker chooses which readable .php file on the server executes, not what code it runs) -- serious LFI, but not automatically RCE. Four conditions must align for the documented RCE chain: (1) a published, anonymous-accessible Page selectable via page_id with no custom template already assigned, (2) the active theme containing a top-level directory beginning with 'page-' (common in legacy default themes such as Twenty Twelve and Twenty Fourteen, and in themes like Neve, Hestia, and Sydney), (3) a readable .php file reachable via traversal that has exploitable runtime behavior, and (4) that file's environment supporting arbitrary content generation. Ressl's laboratory chain used PHP's bundled PEAR command-line entry point, pearcmd.php, which reads command-line-style arguments out of $_SERVER['argv'] when the PHP ini directive register_argc_argv is enabled -- the default in the official PHP Docker images and common in cPanel hosting running PHP versions below 8.5. A first unauthenticated request abuses pearcmd.php's config-create functionality (invoked via a crafted 'pagename' that traversal-includes it, with query-string content acting as PEAR CLI arguments) to write a second, attacker-controlled PHP file to a writable temp directory; a second request re-exploits the same LFI to include that generated file, achieving code execution as the web server's account (www-data in testing). Ressl explicitly cautions that his evidence 'does not establish' that every default WordPress installation is exploitable to full RCE -- the chain is environment-dependent (PEAR availability, register_argc_argv, writable temp paths), not a WordPress-specific guarantee -- but the underlying unauthenticated LFI is present in every affected core version regardless of those conditions.

WordPress disclosed and patched the issue on 2026-09-22. Independent of the vendor advisory, Robert Ressl published a detailed technical write-up and a Docker-based reproduction lab (pinned to wordpress:7.0.2-php8.3-apache with register_argc_argv deliberately enabled) at ressl.ch, and at least two further public PoC repositories (GitHub user abraxas, and a listing by 'pwnVader' indexed on Sploitus) appeared the same day, each independently demonstrating the traversal-to-inclusion primitive with slightly different encoding depth and target-file choices. Patchstack's WAF telemetry recorded the first exploitation probes at 2026-09-22T17:44Z -- under five hours after the WordPress.org patch release -- from a small, concentrated cluster of source addresses (two neighboring IPv4 hosts plus supplementary IPv6 traffic) using automated Go-http-client requests with double-encoded traversal against wp-links-opml.php, wp-includes/functions.php, and wp-cron.php as detection targets; as of the most recent telemetry (2026-09-22T19:51Z) this activity remained reconnaissance/fingerprinting rather than confirmed payload delivery, and the CVE had not yet been added to the CISA KEV catalog. Given WordPress's ~43% share of the web and the fact that a large majority of live installs lag the latest release, and the unusually deep backport (patches were issued all the way back to the 4.7 branch, first released in 2016), the vendor's own patch scope signals broad recognized exposure across long-lived, infrequently-updated WordPress deployments.