CVE-2026-87902

What is WordPress Core?

WordPress is the content management system behind a large share of the public web, running everything from personal blogs to government portals and enterprise marketing sites. "Core" means the base platform itself, as distinct from the plugin and theme ecosystem where most WordPress vulnerabilities normally originate. That distinction matters here. A core bug applies to every installation regardless of which plugins are present, which turns a single flaw into a target list measured in millions of hosts. WordPress also ships automatic background updates for security releases, so the interesting population for an attacker is the sites that have disabled them, run behind a managed host that batches updates, or sit unmaintained.

Overview

CVE-2026-87902 is an unauthenticated path traversal and local file inclusion flaw in WordPress Core's page template resolution. A crafted front-end request causes get_page_template() to include a readable PHP file from outside the active theme directories. The inclusion itself works on any affected installation and requires no authentication and no user interaction. Whether it becomes remote code execution depends on the theme and the server configuration, which is why scoring sources disagree: the NVD entry lists CVSS 3.1 8.1 with high attack complexity, while WordPress and several trackers publish a 9.2 reflecting the unconditional unauthenticated file read.

The bug reaches back to WordPress 4.7.0, released in December 2016, so nearly a decade of releases is affected. WordPress fixed it on September 22, 2026 in 7.1.2 and backported the patch across every supported branch in a single coordinated release.

Exploitation began the same day. Patchstack recorded the first probes hours after the patch went out, escalating within a few more hours to attempts that write web shells to disk. CISA added the CVE to the Known Exploited Vulnerabilities catalog on September 25, 2026, with a remediation deadline of September 28, 2026.

Affected Versions

WordPress published 25 patched releases covering every branch from 4.7 forward. Anything older than 4.7.0 predates the vulnerable code. Sites with automatic background updates enabled should already be on a fixed build; sites that disabled them, or that pin a version through a deployment pipeline, need manual action.

Technical Details

When WordPress resolves which template file should render a page, get_page_template() builds a candidate filename directly from the pagename value in the URL, producing page-{$pagename}.php. Comparable code paths in the template hierarchy run that value through validate_file() first, which rejects directory traversal sequences. This one did not. The result is CWE-98: the attacker controls part of a path that is passed to a PHP include.

Traversal sequences in pagename therefore walk out of the theme directory and include any readable .php file on the filesystem. Reaching code execution needs three conditions to line up. The active theme must contain a top-level directory whose name starts with page-, which anchors the traversal; Twenty Twelve, Twenty Fourteen, Neve, Hestia, and Sydney all qualify. PHP must have register_argc_argv enabled, which is the default in the official WordPress Docker images and in cPanel installations running PHP below 8.5. And a PHP file that does something useful when loaded standalone must exist on the host, in practice PEAR's pearcmd.php. With all three present, an unauthenticated GET or POST is enough.

WordPress did not simply add the missing validate_file() call. The fix introduces _wp_is_template_path_allowed() and applies it across the template system, closing related bypass routes rather than just this one entry point.

Discovery

Robert Ressl found the vulnerability and disclosed it to the WordPress security team, which credited him in advisory GHSA-7hp8-65ch-5whp. He published his own technical write-up covering the traversal primitive and the conditions required to reach code execution.

Exploitation Context

Patchstack observed the first probing attempts at 11:49 UTC on September 22, 2026, within hours of the release. Early requests were reconnaissance: attackers included harmless core files such as wp-links-opml.php and wp-includes/feed-rss2.php, then looked for OPML or RSS output on a normal page URL as a vulnerability oracle. By 15:34 UTC the same day, attempts had moved to PEAR detection, testing /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php, and /usr/share/pear/pearcmd.php with encoded traversals such as pagename=templates%2f<traversal>usr%2flocal%2flib%2fphp%2fpearcmd&+config-show.

Stage three swaps config-show for config-create, writing attacker PHP to /tmp or /var/tmp under names including wp-pear-rce-flag.php, poc87902.php, and randomized luci_* and zeta_* variants. Those files remain reachable over HTTP after the core update, so patching alone does not evict an attacker who already succeeded. Public Nuclei templates appeared on September 23 and traffic rose more than tenfold. Observed user agents include cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0, and a telling request signature is pagename and page_id appearing together. Shadowserver counted more than 350,000 exposed sites as the campaign ran. No named threat actor has been attributed; the traffic pattern is opportunistic mass scanning.

Remediation

1. Update WordPress Core now to 7.1.2 or the patched release for your branch (7.0.6, 6.9.9, 6.8.10, down to 4.7.37). Confirm the version rather than assuming automatic updates applied. The federal deadline is September 28, 2026.
2. Hunt for files already written. List .php files in /tmp and /var/tmp, and search the web root for recently created or modified PHP. The names above are a starting point, but the randomized variants mean timestamp and content review matters more than any filename list.
3. Review access logs for the exploitation signature. Look for %2e%2e or %252e%252e inside the pagename parameter, for pagename and page_id in the same request, and for pearcmd, config-show, or config-create anywhere in a query string. Requests to /index.php or the site root that returned OPML or RSS content indicate a successful probe.
4. Disable register_argc_argv in your PHP configuration unless something needs it. This breaks the pearcmd chain and removes the path from file inclusion to code execution.
5. Remove PEAR if it is not used. pearcmd.php is present by default in many stock images and serves no purpose on a typical WordPress host.
6. Apply a WAF rule as a stopgap if a site cannot be updated immediately. Wordfence, Sucuri, Cloudflare, and Patchstack have published virtual patches. Treat this as temporary cover, not a fix.
7. Assume compromise on any site that was exposed and probed successfully. Rotate database credentials, salts, and administrator passwords, audit users and scheduled tasks, and restore from a known-good backup if a web shell is found.