An unauthenticated attacker can make `get_page_template

CVE-2026-87902 is a path-traversal-to-local-file-inclusion vulnerability in WordPress Core's page-template resolver (get_page_template() in wp-includes/template.php). When WordPress decides which template to render for a page, it builds a candidate filename from the pagename query parameter — page-{pagename}.php — and passes it to locate_template(). A neighboring code path applies validate_file() to block traversal, but the pagename branch does not. An attacker sends a double-URL-encoded traversal sequence (%252e%252e) that survives WordPress's slug sanitizer intact, then gets decoded by a late urldecode() call into ../, escaping the theme directory. Any readable .php file on the server can be included. If the server also has PEAR's pearcmd.php accessible and register_argc_argv=On in the PHP runtime, the attacker chains two requests to write and then execute a webshell — full unauthenticated RCE. Every WordPress version from 4.7.0 through 7.1.1 (a decade of releases across 23 branches) is affected. Fixed in 7.1.2 with backports to 4.7.37.

The GHSA advisory rates this CVSS 4.0: 9.2 (Critical) while a CVSS 3.1 evaluation produces 8.1 (High) — the gap is framework math, not disagreement. The CVSS 4.0 AT:P metric correctly signals that preconditions exist (the active theme must have a page-* directory; RCE further requires pearcmd.php and register_argc_argv), but the 9.2 top-line number overweights the worst-case RCE scenario that only materializes on a subset of deployments. The CVSS 3.1 AC:H captures this conditionality more faithfully. The LFI component alone — which needs only a qualifying theme — is reliably exploitable and serious (it can include core files, leak server-side behavior, and serve as a recon oracle), but it is not arbitrary code execution on every host. HIGH at 8.1 is the honest read: dangerous enough to demand immediate action, conditional enough that not every WordPress site is equally at risk.

1. Deploy WAF rule blocking double-encoded traversal in pagename — Add a WAF rule (ModSecurity, Cloudflare, AWS WAF) that rejects requests where the pagename query parameter (GET or POST) contains %252e or %252f after URL decoding. This is the most targeted compensating control and does not affect legitimate traffic — no valid WordPress page slug contains percent-encoded dots. Given active probing and the noisgate exploitation override, deploy within hours, not 30 days. Test against your staging environment first to confirm no false positives on slug-based routing.
2. Switch to a theme without a page-* directory — If patching is delayed, activate a theme that does not contain a top-level page-* directory (e.g., Twenty Twenty-One through Twenty Twenty-Six use different layouts). This eliminates the LFI precondition entirely. Verify by listing ls -d /path/to/themes/*/page-* — if nothing returns, the precondition is not met. Deploy within the noisgate exploitation override window (hours).
3. Remove or restrict pearcmd.php — Delete /usr/share/php/pearcmd.php (or equivalent path) or make it unreadable by the web server user. This collapses the RCE chain entirely, even if the LFI succeeds. On Docker PHP images: rm /usr/local/lib/php/pearcmd.php. On cPanel: chmod 000 /usr/share/pear/pearcmd.php. Deploy within hours on internet-facing hosts.
4. Disable register_argc_argv in php.ini — Set register_argc_argv = Off in the PHP configuration used by the web server (not just the CLI php.ini). Restart PHP-FPM or Apache. This prevents pearcmd.php from reading attacker-controlled arguments even if included. Verify with php -i | grep register_argc_argv from the web server context. Deploy within hours on internet-facing hosts.
5. Monitor access logs for traversal indicators — Set up real-time log alerting for requests where the pagename parameter contains %252e, %252f, .., or references to pearcmd, wp-links-opml, or wp-cron in unexpected contexts. Patchstack documented specific IoC patterns: User-Agent Go-http-client/1.1, IPs 169.58.48.193 and 169.58.48.195. Alert on these immediately.
6. Patch to WordPress 7.1.2 or branch backport — This is the definitive fix. Update via the WordPress dashboard (auto-update if enabled) or manually apply the branch-specific backport (7.0.6, 6.9.9, 6.8.10, down to 4.7.37). The patch adds validate_file() to the pagename branch and introduces _wp_is_template_path_allowed() with realpath() containment. Under the noisgate remediation SLA for HIGH, the deadline is 180 days, but given active probing, prioritize internet-facing instances this week.

Run this script on the WordPress host (or any machine with read access to the webroot via mount/SSH). Invoke with bash cve-2026-87902-check.sh /var/www/html (adjust the path to your WordPress document root). No elevated privileges required — only read access to wp-includes/. The script also checks RCE preconditions (pearcmd.php, register_argc_argv) which may require broader read access.

#!/usr/bin/env bash
# CVE-2026-87902 — WordPress Core LFI via page-template resolution
# Usage: bash cve-2026-87902-check.sh /var/www/html
# Exit: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -uo pipefail

WP="${1:?Usage: $0 /path/to/wordpress}"
TMPL="$WP/wp-includes/template.php"
VERF="$WP/wp-includes/version.php"

if [ ! -f "$VERF" ]; then
  echo "UNKNOWN - $VERF not found. Is this a WordPress webroot?"
  exit 2
fi

wp_ver=$(awk -F"'" '/wp_version/{print $2;exit}' "$VERF")
echo "[*] WordPress version: $wp_ver"

if [ ! -f "$TMPL" ]; then
  echo "UNKNOWN - $TMPL not found."
  exit 2
fi

# Primary check: does template.php contain the fix?
if grep -q '_wp_is_template_path_allowed' "$TMPL" 2>/dev/null; then
  echo "PATCHED - template.php contains the CVE-2026-87902 fix (_wp_is_template_path_allowed)."
  exit 0
fi

echo "VULNERABLE - template.php lacks the CVE-2026-87902 fix (v$wp_ver)."
echo ""
echo "--- Precondition checks ---"

# Check 1: Theme has page-* directory (LFI precondition)
THEMES="$WP/wp-content/themes"
if [ -d "$THEMES" ]; then
  hits=$(find "$THEMES" -maxdepth 2 -type d -name 'page-*' 2>/dev/null)
  if [ -n "$hits" ]; then
    echo "  WARN: page-* directory found in themes - LFI precondition MET"
    echo "$hits" | sed 's/^/    /'
  else
    echo "  INFO: No page-* directory in themes - LFI precondition not met (lower risk)"
  fi
fi

# Check 2: pearcmd.php exists (RCE precondition)
pear=$(find / -name pearcmd.php -readable 2>/dev/null | head -1)
if [ -n "$pear" ]; then
  echo "  WARN: pearcmd.php found at $pear - RCE escalation path exists"
else
  echo "  INFO: pearcmd.php not found - RCE chain unlikely"
fi

# Check 3: register_argc_argv enabled (RCE precondition)
if command -v php >/dev/null 2>&1; then
  argc=$(php -r 'echo ini_get("register_argc_argv");' 2>/dev/null || true)
  if [ "$argc" = "1" ]; then
    echo "  WARN: register_argc_argv is ON - RCE precondition met"
  else
    echo "  INFO: register_argc_argv is OFF or unset"
  fi
else
  echo "  INFO: php binary not in PATH - cannot check register_argc_argv"
fi

exit 1

1. GHSA Advisory — WordPress/wordpress-develop
2. Patchstack — Attackers Started Probing Hours After the Patch
3. Robert Ressl — Researcher Writeup
4. Hadrian — Working PoC Analysis
5. WordPress 7.1.2 Release Announcement
6. SecurityOnline — Critical WordPress RCE Flaw
7. griisemine — Nuclei Detection Template
8. abraxas — Public PoC Repository