WordPress Core shipped an emergency fix on September 22, 2026 for CVE-2026-87902, a critical unauthenticated path traversal and local file inclusion bug in the page-template resolution logic — and attackers started scanning for vulnerable sites less than five hours after the patch landed. CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 25, giving federal agencies until September 27-28 to remediate. Given WordPress’s install base, this is a today problem for anyone running self-hosted WordPress.

What happened

Security researcher Robert Ressl privately reported the bug to the WordPress security team via HackerOne on July 20, 2026. WordPress patched it and published a public advisory on September 22 with the release of version 7.1.2 (also backported to 7.0.6, 6.9.9, and 6.8.10). Patchstack recorded the first exploitation attempts at 11:49 UTC that same day — meaning the window between patch and active attack was measured in hours, not days.

Technical details

The bug lives in get_page_template(), the function WordPress Core uses to resolve which template file to load for a given page request. A crafted frontend request supplies a pagename parameter — often double-URL-encoded to slip past naive input filtering — that WordPress fails to properly constrain to the active theme’s directory. The function will happily traverse outside the theme folder and include() any readable PHP file on the filesystem that a crafted path points to.

By itself, that’s local file inclusion (LFI): CVE-2026-87902 carries a CVSS v4.0 score of 9.2 and requires no authentication or user interaction. Escalating LFI to remote code execution requires either finding an existing PHP file on disk that an attacker can influence the contents of, or a way to plant one. Researchers and now live attackers found both:

  • Conditional RCE via the active theme. If the site’s active theme has a top-level directory whose name starts with page- (a fairly common WordPress naming convention for custom page templates), and an attacker can get a .php file into that path, get_page_template() will execute it directly.
  • RCE via bundled pearcmd.php. Many PHP environments ship PEAR’s pearcmd.php binary, which supports a config-create option that can be abused to write attacker-controlled content to an arbitrary file, including one with a .php extension. Attackers are chaining the traversal to invoke pearcmd.php’s config-create primitive, writing a small PHP webshell to disk, then hitting the traversal a second time to execute it — turning an LFI into a full unauthenticated RCE chain with no plugin or theme misconfiguration required beyond pearcmd.php being present, which it is on a large fraction of shared hosting stacks.

Affected: WordPress Core 4.7.0 through 7.1.1 Patched in: 7.1.2, 7.0.6, 6.9.9, 6.8.10 Attack vector: Network, unauthenticated, no user interaction CVSS: 9.2 (v4.0) Disclosed by: Robert Ressl via HackerOne, coordinated disclosure through the WordPress security team First observed exploitation: September 22, 2026, ~5 hours after patch release Added to CISA KEV: September 25, 2026

Indicators of compromise

Defenders should check for:

  • Requests carrying double-URL-encoded traversal sequences in the pagename parameter, frequently paired with a page_id value, in access logs
  • Unexpected PHP files dropped in /tmp or /var/tmp with names such as wp-pear-rce-flag.php, poc87902.php, or randomized names matching patterns like luci_<random>.php and zeta_<random>.php
  • Requests referencing pearcmd.php from an unauthenticated frontend context — this file should never be reachable from normal WordPress traffic
  • Connections from source IPs 169.58.48.193, 169.58.48.195, and 2001:df1:e8c0::106b, observed in confirmed exploitation attempts

Impact

WordPress powers a substantial share of the public web, and this bug is present in every core release back to 4.7.0 — effectively any WordPress install that hasn’t updated in the last several years is vulnerable, with no dependency on a specific plugin or theme. The pearcmd chain requires no special site configuration beyond a PHP environment that includes PEAR’s command-line tooling, which is common on shared hosting and many managed WordPress platforms. Because the flaw is both unauthenticated and remotely triggerable with public scanning tooling already circulating, treat any unpatched, internet-facing WordPress site as presumed-targeted, not merely at-risk.

Mitigation

  1. Patch immediately to WordPress 7.1.2, or the corresponding backport (7.0.6, 6.9.9, 6.8.10) for your branch. Most managed hosts push this automatically for security releases of this severity — verify rather than assume.
  2. Audit for the IOCs above — grep access logs for double-encoded pagename traversal patterns, and search the filesystem for the named webshell files and any unrecognized .php files under page-* theme directories or in /tmp//var/tmp.
  3. Remove or restrict pearcmd.php if it isn’t required — delete it, or block direct web access to it via server config, closing off the primary RCE chain even before patching.
  4. Block the known scanning IPs listed above at the WAF or firewall layer as a stopgap while patching rolls out.
  5. Treat any site showing IOC matches as compromised — rotate WordPress secrets (AUTH_KEY, SECURE_AUTH_KEY, etc.), audit for new admin users and unrecognized files, and restore from a known-good backup rather than trusting the live filesystem.

References