WordPress Core CVE-2026-87902: Page-Template Path Traversal to pearcmd Remote Code Execution

What the attacker wants: code execution on an internet-facing WordPress host, reached without a credential and without a single byte of user interaction. CVE-2026-87902 is a path-traversal flaw in how WordPress core resolves which template file to load for a page. The pagename request parameter feeds get_page_template(); WordPress's own sanitiser strips literal ../ sequences but deliberately preserves percent-encoded octets, so a double URL-encoded traversal payload (%252e%252e) survives sanitisation, gets decoded later, and lets the attacker point the template loader at any readable local .php file outside the active theme. On its own that is an information-disclosure-grade local file inclusion. It becomes remote code execution when two ordinary conditions both hold: the active theme ships a top-level directory whose name starts with page- (Twenty Twelve, Twenty Fourteen, and third-party themes Neve, Hestia and Sydney all qualify), and PEAR's pearcmd.php is present and readable with register_argc_argv enabled in PHP, which is the default in the official PHP Docker image and in cPanel builds on PHP below 8.5. When both hold, the query string is exposed to pearcmd.php as $argv, and its config-create directive will write attacker-controlled PHP content to an arbitrary writable path.

Why it matters operationally: the gap between patch and exploitation was measured in hours, not days. WordPress 7.1.2 (plus 7.0.6, 6.9.9, 6.8.10 and backports to every branch down to 4.7.37) shipped 2026-09-22 alongside advisory GHSA-7hp8-65ch-5whp; Patchstack logged the first probing attempt at 11:49 UTC that same day and the first successful file-write attempt at 15:34 UTC. By 2026-09-23 a named Nuclei template and dedicated scanner tooling were in public circulation, CrowdSec's virtual-patch rule went live, and traffic had moved from reconnaissance to active file-write attempts. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 2026-09-25 with a federal remediation deadline of 2026-09-28. CrowdSec's network recorded 322,680 matching signals between 2026-09-23 and 2026-09-27 alone, distinct source addresses growing from 237 to 23,321 across those five days and reaching 30,813 cumulative unique IPs by 2026-09-28, while signals per source fell from roughly 63 to roughly 5, the textbook signature of an exploit moving from a handful of operators into commodity mass-scanning tooling.

The highest-value defensive angle for Falcon: not the HTTP request, the consequence of a successful chain. A Falcon sensor on the web server never sees a pagename parameter, a percent-encoded traversal sequence, or the cve-2026-87902-poc/1.0 user agent; those live in web-server, WAF and CDN logs. What the sensor sees cleanly is what happens after the include succeeds and the dropped payload runs: a web-server or PHP process (httpd, nginx, php-fpm, php-cgi, or w3wp.exe on IIS) spawning a shell or scripting interpreter. That parent-child relationship is close to zero in a healthy estate, it fires regardless of which of the reported dropped-file names appears, and it is the pack's spine. The atomic indicators (two literal dropped filenames, two scanner user agents, a handful of request markers) are useful corroboration, not the plan.

Defender priority: confirm every WordPress host you own is running 7.1.2, 7.0.6, 6.9.9, 6.8.10 or a later backport, then assume the window from 2026-09-22 to your patch time was hostile and hunt it. Disabling register_argc_argv and removing pearcmd.php breaks the RCE escalation specifically, but the underlying LFI persists until you patch. Run Q1 and Q2 (Section 8) across the last 30 days before you close this out, and do not assume auto-updates saved you. The exposure concentrates precisely on the sites where someone turned them off.

Conflict noted, not resolved: WordPress's own advisory scores this CVSS 4.0 9.2 Critical, where the theme and server preconditions are modelled as "Attack Requirements" and complexity stays Low. NVD and CISA score the same flaw CVSS 3.1 8.1 High, where the identical preconditions are modelled as High Attack Complexity. Same vulnerability, two scoring frameworks, two numbers. This pack treats it as critical on the basis of unauthenticated code execution and CISA KEV inclusion, and records the disagreement rather than picking a winner. Verify against your own risk register's scoring convention before quoting a single number.

Single-sourced detail, deliberately not shipped as an indicator: The Hacker News quotes Previdian's founder describing honeypot traffic from one IP address (in the New Jersey area) that chained pearcmd.php inclusion, a file write to /tmp/, and then a second inclusion of a PHP uploader hosted on GitHub. This is a real and specific report, but it is corroborated by none of the other four sources in this table, and per this pack's provenance standard nothing ships as a confirmed indicator on a single citation. The IP and the GitHub path are discussed here for analyst context only; neither appears in Section 4's IOC table, Section 8's CQL, or Section 10's machine-readable appendix.

Provenance discipline: the raw fetched text of every source above is saved alongside this file in WordPress-CVE-2026-87902-RFI-Hunt-sources/ (eight snapshots: Patchstack, CrowdSec, The Hacker News, SecurityWeek, NVD, CISA KEV, the GHSA advisory, and the MITRE CVE record). Every atomic indicator shipped in Section 10 traces to one of those snapshots. Nothing in this pack was written from memory, and no fetched page contained instructions directed at an automated agent.

Attack chain

Hunt hypotheses (ordered by fidelity)

Read the Action column before you build anything from this table. Every row here is request-level or filesystem-level, not a hash or a network indicator, and none of it appears in Falcon endpoint telemetry directly. No malware hashes and no payload-hosting infrastructure have been confirmed across two or more of this pack's sources as of 2026-09-29 (see the single-sourced note in Section 2), so nothing here ships as a Falcon Custom IOC Management row. The commodity attacking-IP set CrowdSec measured (30,813 addresses and rising) is deliberately not listed as a blocklist: at that scale and turnover rate a static IP list is stale before it is imported, and blocking by source address teaches nothing about whether a given host was actually compromised.

Why this section exists. Steps 1 through 3 of the attack chain (recon, pearcmd reachability check, file write) leave no endpoint trace at all. They live entirely in web-server, WAF and CDN logs. An EDR sensor cannot see a pagename parameter. Treat the checks below as first-class hunt work, not as an appendix to the CQL, and note explicitly: a request that never got past the theme-directory precondition leaves no artifact anywhere, on the host or in a response body that differs from a normal 404. Absence of a hit here is not proof the host was never probed.

N1 · Web-server access logs, exploitation attempts and successes

Run on each WordPress host, or against centralised HTTP logs. Cover 2026-09-21 onward, or from the last known-good backup if earlier.

# The two published exploitation/scanner user agents
grep -aEi 'cve-2026-87902-poc|nuclei-cve-2026-87902' /var/log/nginx/access.log* /var/log/apache2/access.log*

# Core traversal marker in the pagename parameter, query string or POST body,
# single or double URL-encoded
grep -aEi 'pagename=[^ ]*(%2e%2e|%252e%252e|\.\.)' /var/log/nginx/access.log* /var/log/apache2/access.log*

# pearcmd escalation markers -- stage two (reachability) and stage three (write)
grep -aEi 'pearcmd|\+config-show|\+config-create' /var/log/nginx/access.log* /var/log/apache2/access.log*

# pagename and page_id co-occurring at the site root or /index.php -- the pairing
# needed to actually reach the vulnerable code path
grep -aEi '(\?|&)page_id=[0-9]+.*pagename=|pagename=.*(\?|&)page_id=[0-9]+' /var/log/nginx/access.log* /var/log/apache2/access.log*

# Stage-one confirmation: a 200 response to a pagename-driven request for a core
# file that should never render standalone
awk '$0 ~ /pagename=/ && ($9 == 200)' /var/log/nginx/access.log | grep -aEi 'wp-links-opml|feed-rss2|wp-cron'

Read the response body, not just the status code, on that last check. Per Patchstack, a 200 response to a pagename-driven request for wp-links-opml.php or wp-includes/feed-rss2.php that actually returns OPML or RSS content is the confirmation the inclusion ran on that host. That is a materially stronger finding than a blocked or 404'd probe, and it means the exposure window should be treated as a confirmed vulnerable period, not merely a scanned one.

N2 · WAF / CDN edge

• Confirm a block rule exists for the pagename traversal pattern in both the query string and the POST body. WordPress reads pagename from the POST body in preference to the query string, and Patchstack reports POST has overtaken GET as the more common delivery method.
• If you run CrowdSec, confirm the crowdsecurity/vpatch-CVE-2026-87902 AppSec rule is enabled and set to block, not log.
• Confirm the rule matches traversal depth from one to twelve levels and both single and double percent-encoding (including uppercase hex), per the payload variation Patchstack has observed. A rule anchored to one exact depth or encoding will miss most of the traffic.

N3 · Filesystem outside the web root, dropped-payload hunt

# Any PHP file in /tmp or /var/tmp created or modified since the day before disclosure
find /tmp /var/tmp -maxdepth 2 -name '*.php' -newermt '2026-09-21' -printf '%T+ %s %p\n' 2>/dev/null | sort

# The two exact reported dropped filenames, anywhere under /tmp or /var/tmp
find /tmp /var/tmp -maxdepth 2 \( -name 'wp-pear-rce-flag.php' -o -name 'poc87902.php' \) 2>/dev/null

# The randomised-prefix pattern
find /tmp /var/tmp -maxdepth 2 -regextype posix-extended -regex '.*/(luci_|zeta_)[A-Za-z0-9]+\.php' 2>/dev/null

# Confirm whether pearcmd.php exists and is readable at any of the three known paths
for p in /usr/local/lib/php/pearcmd.php /usr/share/php/pearcmd.php /usr/share/pear/pearcmd.php; do
  [ -r "$p" ] && echo "READABLE: $p"
done

# Suspicious shell-out primitives, or the chr()-assembled marker pattern Patchstack
# reported, in any PHP file dropped since disclosure
grep -rlE 'shell_exec|passthru|proc_open|popen|(chr\([0-9]+\)\s*\.\s*){6,}' /tmp /var/tmp --include='*.php' 2>/dev/null

A file in /tmp is not normally reachable over the web on its own; per Patchstack this is evidence of proof of execution, not necessarily a persistent web-reachable backdoor. Treat any hit above as a confirmed compromise regardless of whether the file is externally reachable, since the same file-write primitive can be pointed at a more useful location on a second attempt.

N4 · PHP runtime and theme precondition audit

• Check register_argc_argv in every php.ini / pool configuration in the estate. On plus a readable pearcmd.php is what turns this from an information leak into code execution.
• Enumerate active themes for a top-level directory whose name starts with page-. Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney are named in the advisory as meeting this condition; a custom or unlisted theme can too.
• Confirm WordPress core version on every install. Anything below 7.1.2 on the 7.1 branch, 7.0.6 on the 7.0 branch, 6.9.9 on the 6.9 branch, 6.8.10 on the 6.8 branch, or the equivalent backported fix on any older branch down to 4.7.37, is exposed to the LFI regardless of the RCE preconditions.

Scope note, endpoint telemetry only. None of the queries below can see an HTTP request path, a response code, or a user-agent string. Falcon's sensor observes processes, files and sockets, not the web server's request handling. Every query here therefore targets what the exploit chain does after the dropped payload executes. The request-level indicators are hunted in Section 7 against web and proxy logs. If you have HTTP logs in NG-SIEM the same markers can be queried there, but field names are parser-specific to your ingest and must be validated against a real sample row before use; this pack does not guess at them.

No query carries an in-query time filter. Set the window with the Falcon console time picker; each card records the intended lookback as a // LOOKBACK: comment. Start at 30 days and widen to cover the interval from 2026-09-22 to the moment your estate patched. Where a query targets both platforms, Linux and Windows events differ (ELFFileWritten is Linux-only, NewExecutableWritten is Windows-only, ProcessRollup2 covers both); each card's // REQUIRES line says which.

// HUNT: Web-server or PHP process spawning a shell or interpreter (post-exploitation execution)
// MITRE: T1190, T1505.003, T1059.004, T1059.003 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with parent lineage. Covers both Linux (php-fpm/httpd/nginx -> sh/bash)
// REQUIRES: and Windows (w3wp.exe/php-cgi.exe -> cmd.exe/powershell.exe) web hosts in one query.
// FALSE POSITIVES: CMS cron jobs, backup/migration plugins, WP-CLI wrappers, deploy hooks
// TUNING: exclude your deploy and backup service accounts by UserName, and your CI/CD build hosts
// TUNING: by ComputerName; then re-run and treat whatever remains as a genuine lead
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php[0-9.]*-fpm|php-cgi|httpd|apache2|nginx|lsphp|litespeed|w3wp\.exe)$/i
| FileName=/^(sh|bash|dash|zsh|ksh|busybox|python[0-9.]*|perl|ruby|node|cmd\.exe|powershell\.exe|pwsh\.exe)$/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Discovery commands executed under a web-server parent (post-exploitation recon)
// MITRE: T1033, T1082 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with parent lineage on web hosts, Linux and Windows
// FALSE POSITIVES: monitoring agents, container health checks and readiness probes running as the web user
// TUNING: exclude the ComputerName of dedicated build and monitoring boxes; exclude the UserName your
// TUNING: observability agent runs as. Do NOT exclude the binaries themselves - they are the signal.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(sh|bash|dash|php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|w3wp\.exe)$/i
| FileName=/^(whoami|id|uname|hostname|hostnamectl|ifconfig|ip|netstat|ss|ps|env|lsb_release|systeminfo\.exe|net\.exe|net1\.exe|nslookup)$/i
| groupBy([ComputerName, UserName, ParentBaseFileName], function=[count(as=Hits), collect([FileName, CommandLine], limit=40)], limit=200)
| sort(Hits, order=desc, limit=100)

// HUNT: PHP file written under /tmp or /var/tmp (pearcmd config-create artifact) via FIM telemetry
// MITRE: T1505.003 | CONF: medium  FP: medium  COST: low
// REQUIRES: CriticalFileModified - needs a FileVantage/FIM policy covering /tmp and /var/tmp, which is
// REQUIRES: atypical. Without that policy this query returns nothing even on a compromised host - see
// REQUIRES: Section 7 N3 for the host-side scan that is the real coverage of this step.
// FALSE POSITIVES: legitimate temp-file writes by session handlers, upload processing, caching layers
// TUNING: correlate every survivor against Q1 on the same ComputerName within a few minutes; a lone
// TUNING: temp-file write with no shell nearby is usually unrelated application behaviour
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^CriticalFileModified$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|w3wp\.exe)$/i
| TargetFileName=/\/(tmp|var\/tmp)\/[^\/]+\.php$/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, TargetFileName, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Published CVE-2026-87902 dropped-payload filename in file-write telemetry
// MITRE: T1505.003 | CONF: high  FP: low  COST: low
// REQUIRES: CriticalFileModified - same FIM-on-/tmp caveat as Q3. Matched on basename via FileName so
// REQUIRES: no path separator appears inside the regex.
// FALSE POSITIVES: none expected - any hit is a confirmed incident
// LOOKBACK: 90d (set in the console time picker)
#event_simpleName=/^CriticalFileModified$/
| FileName=/^(wp-pear-rce-flag\.php|poc87902\.php|luci_[a-z0-9]{4,}\.php|zeta_[a-z0-9]{4,}\.php)$/i
| table([@timestamp, ComputerName, UserName, FilePath, FileName, TargetFileName, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Download utility launched by a web-server process (second-stage retrieval)
// MITRE: T1105 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with CommandLine, Linux and Windows
// FALSE POSITIVES: plugin/theme update routines, composer and npm installs run as the web user
// TUNING: exclude CommandLine values pointing at your internal package mirror and at wordpress.org;
// TUNING: exclude CI/CD hosts by ComputerName. Keep curl and wget in scope - narrow the destination.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|sh|bash|dash|w3wp\.exe)$/i
| FileName=/^(curl|wget|fetch|bitsadmin\.exe|certutil\.exe|powershell\.exe|pwsh\.exe|python[0-9.]*)$/i
| CommandLine=/(http:|https:|ftp:|--output|-OutFile|Invoke-WebRequest|DownloadString|DownloadFile|urlcache)/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Persistence mechanism created from a web-server process tree
// MITRE: T1053.003, T1053.005 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 with parent lineage, Linux and Windows
// FALSE POSITIVES: rare - some shared-hosting control panels register cron jobs as the web user
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|sh|bash|dash|w3wp\.exe|cmd\.exe|powershell\.exe)$/i
| FileName=/^(crontab|at|systemctl|systemd-run|schtasks\.exe|sc\.exe|reg\.exe|useradd|adduser|usermod)$/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: SSH key material touched from a web-server process tree (authorized_keys persistence)
// MITRE: T1098.004, T1552.004 | CONF: medium  FP: low  COST: low
// REQUIRES: ProcessRollup2 with CommandLine on Linux/Unix web hosts
// FALSE POSITIVES: rare - configuration management tooling that legitimately provisions SSH keys
// TUNING: exclude your CM tool's binary and its service account if it manages keys by design
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|sh|bash|dash)$/i
| CommandLine=/(authorized_keys|ssh-keygen|\.ssh\/id_rsa|\.ssh\/id_ed25519)/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Web-server process making outbound connections, ranked by destination rarity
// MITRE: T1071.001 | CONF: medium  FP: high  COST: medium
// REQUIRES: NetworkConnectIP4, Linux and Windows web hosts
// FALSE POSITIVES: high by design - package mirrors, license-check callbacks, CDN edges, your own DB
// TUNING: run once to baseline, then exclude your known CDN/mirror/DB destinations by RemoteAddressIP4
// TUNING: or by ASN if your pipeline enriches it; re-run and read only what is left. Never promote this
// TUNING: query to a Scheduled Search without that exclusion list built from your own baseline first.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^NetworkConnectIP4$/
| ContextBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|w3wp\.exe)$/i
| !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","127.0.0.0/8"])
| groupBy([ComputerName, RemoteAddressIP4], function=[count(as=Hits), collect([RemotePort], limit=10)], limit=500)
| sort(Hits, order=asc, limit=150)

// HUNT: Rare child processes of web-server parents (catch-all for unnamed payloads)
// MITRE: T1190, T1505.003 | CONF: medium  FP: high  COST: medium
// REQUIRES: ProcessRollup2 across every web host in the estate, Linux and Windows
// FALSE POSITIVES: high by design. The common rows are your normal; the sparse tail is the signal.
// TUNING: read only rows where Hosts is 1 or 2 - a child seen fleet-wide is infrastructure, not an
// TUNING: intrusion. Once baselined, exclude your CMS cron and backup binaries by FileName. Never
// TUNING: promote this query to a Scheduled Search without that exclusion list in place.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php[0-9.]*-fpm|php-cgi|httpd|apache2|nginx|lsphp|litespeed|w3wp\.exe)$/i
| groupBy([FileName], function=[count(as=Execs), count(ComputerName, distinct=true, as=Hosts), collect([CommandLine], limit=5)], limit=500)
| sort(Execs, order=asc, limit=120)

Custom IOA candidates

Not IOA candidates: Q2, Q3, Q4, Q8 and Q9 stay Investigate-only. Q2 is a volume hunt best triaged in bulk, Q3 and Q4 depend on FIM policy coverage of /tmp that varies wildly by host group, Q8 and Q9 are explicitly stack-ranking hunts with FP high by design, and none of the four should fire an alert until they have been baselined per-estate. Promoting any of them without the tuning in their cards will train analysts to ignore the whole rule family.

Scheduled Search packaging (for the promoted IOAs)

Alert email body (template)

WHAT FIRED
A web-server or PHP process spawned an interactive shell or scripting interpreter
on a host in the WordPress server group.

  Host          : {{ComputerName}}
  User          : {{UserName}}
  Parent        : {{ParentBaseFileName}}
  Child         : {{FileName}}
  Command line  : {{CommandLine}}
  First seen    : {{@timestamp}}

WHAT IT MEANS
A healthy web server almost never launches a shell. This parent-child pair is the
execution signature of a web shell. Given active in-the-wild exploitation of
CVE-2026-87902 (WordPress page-template path traversal to pearcmd RCE), treat this
as a probable post-exploitation event until proven otherwise.

IMMEDIATE ACTIONS
  1. Do not reboot or reimage yet, capture volatile state first.
  2. Network-contain the host in Falcon if the command line shows recon,
     credential access, or an outbound download.
  3. Confirm the WordPress version. Anything below 7.1.2 / 7.0.6 / 6.9.9 / 6.8.10
     (or the branch-matched backport) is vulnerable; treat the host as compromised.
  4. Run the Section 7 N3 filesystem hunt (/tmp, /var/tmp) on this host.
  5. Preserve the web-server access log before rotation removes the request that
     triggered the shell.

ESCALATION
  Confirmed webshell    -> incident response, severity 1
  Unexplained but clean -> hunt lead, 24h follow-up
  Matched exclusion     -> tune the rule, record the exclusion, close

L1 triage checklist

1. Record host, user, parent, child and full command line from the detection before touching anything.
2. Check the WordPress version on the host. A vulnerable version plus this alert equals a presumed compromise.
3. Pivot the host into Q2, Q5, Q6 and Q7 scoped to the same ComputerName and a window of a few hours either side. A lone shell is ambiguous; a shell followed by whoami and curl is not.
4. Run the Section 7 N3 filesystem hunt on the host: recently modified PHP in /tmp//var/tmp, the two exact filenames, and the luci_/zeta_ pattern.
5. Grep the web-server access log for the pagename traversal marker, the pearcmd markers, and the two user agents, restricted to the hours before the alert.
6. Check whether register_argc_argv is On and whether pearcmd.php is present and readable on the host. If both, the RCE precondition was met and this alert should be treated at higher confidence.
7. If two or more of steps 4 to 6 return findings, escalate to incident response and move to the Section 14 containment runbook. If all are clean and the parent command line matches a documented exclusion, tune and close with the exclusion recorded.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_SHA256_OF_YOUR_OWN_RECOVERED_DROPPED_PHP_FILE,prevent,critical,2026-12-29,CVE-2026-87902 locally recovered pearcmd-dropped PHP payload,campaign:cve-2026-87902
# No file hashes and no payload-hosting infrastructure have been published across two
# or more of this pack's sources as of 2026-09-29 (see Section 2 for the single-sourced
# exception, which is deliberately not shipped here). The two reported dropped-file
# names are literal filenames, not hashes or domains, and Falcon Custom IOC Management
# accepts only sha256, md5, domain, ipv4 and ipv6 - a filename type cannot be imported.
# They are hunted via FileName regex in Q4 and via the host-side find in Section 7 N3
# instead. If you recover a sample locally, compute its SHA256 and replace the row above.
# wp-pear-rce-flag.php
# poc87902.php
# luci_<random>.php
# zeta_<random>.php

PROCESS LINEAGE
  php | php-fpm | php-cgi | httpd | apache2 | nginx | lsphp | w3wp.exe
    -> sh | bash | dash | zsh | busybox | python | perl | cmd.exe | powershell.exe
  same parents -> whoami | id | uname | hostname | ss | netstat
  same parents -> curl | wget | certutil.exe   (command line contains a URL)
  same parents -> crontab | systemctl | schtasks.exe | useradd
  same parents -> ssh-keygen | commands referencing authorized_keys

FILESYSTEM
  new or modified *.php under /tmp or /var/tmp (NOT the WordPress web root - this
    campaign drops outside it, unlike a typical webshell-in-plugins pattern)
  exact filenames: wp-pear-rce-flag.php | poc87902.php
  pattern filenames: luci_<random>.php | zeta_<random>.php
  marker string CVE-2026-87902-POC-OK, or an obfuscated marker assembled via
    chained chr() calls (reported form: LUCIFER-RCE-OK)
  pearcmd.php present and readable at one of three install paths:
    /usr/local/lib/php/pearcmd.php | /usr/share/php/pearcmd.php | /usr/share/pear/pearcmd.php

HTTP  (web / WAF / proxy logs only - NOT visible to the endpoint sensor)
  pagename parameter containing .. or %2e%2e, single or double encoded, in the
    query string or the POST body (POST has overtaken GET as the common method)
  pagename beginning with templates/ or another page-<name> directory
  pagename and page_id present together on the site root or /index.php
  request containing pearcmd, +config-show, or +config-create
  User-Agent contains: cve-2026-87902-poc/1.0 | nuclei-cve-2026-87902/1.0
  200 response to a pagename-driven request for wp-links-opml.php, wp-cron.php or
    wp-includes/feed-rss2.php that returns actual OPML/RSS content (confirms the
    inclusion ran, not just that it was attempted)

CAMPAIGN   None. No vendor-assigned campaign or actor name has been published for this
           exploitation activity; reporting refers to it by CVE only. CISA's assigned
           vulnerability name is "WordPress Core Remote File Inclusion Vulnerability".
CVE        CVE-2026-87902   WordPress core page-template path traversal / LFI, conditional RCE
           CVSS 4.0: 9.2 Critical (WordPress/GHSA)   CVSS 3.1: 8.1 High (NVD/CISA) - disputed, see Section 2
           CWE-98 Remote File Inclusion (authoritative, MITRE CVE record). Patchstack additionally
           describes it as "Path Traversal leading to Local File Inclusion" (CWE-22 family behaviour).
DISCOVERY  Robert Ressl, via the WordPress HackerOne programme
DISCLOSED  2026-09-22   EXPLOITED ITW from 2026-09-22 11:49 UTC (Patchstack), first file-write attempt
           2026-09-22 15:34 UTC. KEV added 2026-09-25, federal deadline 2026-09-28.

VULNERABLE   4.7.0 - 7.1.1 across every branch (full per-branch matrix in GHSA-7hp8-65ch-5whp)
PATCHED      7.1.2 | 7.0.6 | 6.9.9 | 6.8.10 and backports on every branch down to 4.7.37

ROOT CAUSE  get_page_template() builds a template filename from the pagename request parameter.
            WordPress's sanitiser strips literal ../ but preserves percent-encoded octets; a later
            urldecode() turns a double-encoded traversal payload into a real path, and the resulting
            file is loaded with include(). The code path skips the validate_file() check used
            elsewhere in core for the same class of filename.

RCE PRECONDITIONS (both required)
  1. Active theme has a top-level directory starting with page- (Twenty Twelve, Twenty
     Fourteen, Neve, Hestia, Sydney are named; a custom theme can also qualify)
  2. A readable local .php file exists for pearcmd.php RCE: register_argc_argv On
     (default in the official PHP Docker image and cPanel PHP < 8.5) plus pearcmd.php
     present at a standard PEAR install path

ATTACK PROGRESSION (Patchstack, three stages)
  1. Recon: pagename points at a harmless core file to confirm the inclusion is live
  2. pearcmd reachability: pagename + config-show confirms PEAR present and argv works
  3. File write: pagename + config-create writes attacker PHP to /tmp or /var/tmp

SCALE (CrowdSec, 2026-09-23 to 2026-09-28)
  322,680 signals over 5 days, daily volume 14,938 -> 124,154
  distinct sources 237 -> 23,321; 30,813 cumulative unique IPs by 2026-09-28
  signals-per-source fell from ~63 to ~5 (mass scanner commoditisation)

CAVEAT  No malware hashes and no corroborated (two-plus-source) payload-hosting
        infrastructure exist for this campaign as of 2026-09-29. Treat any IOC feed
        claiming otherwise with the same scrutiny this pack applied in Section 2.

# 1. Enumerate WordPress versions across the estate
find / -name version.php -path '*wp-includes*' 2>/dev/null \
  | while read -r f; do printf '%s ' "$f"; grep -m1 wp_version "$f"; done

# 2. With WP-CLI, per site root
wp core version --allow-root
wp core check-update --allow-root
wp theme list --fields=name,status --allow-root

# 3. Confirm the RCE preconditions on each host
php -i 2>/dev/null | grep -i register_argc_argv
for p in /usr/local/lib/php/pearcmd.php /usr/share/php/pearcmd.php /usr/share/pear/pearcmd.php; do
  [ -r "$p" ] && echo "READABLE: $p"
done
find /var/www -maxdepth 3 -type d -iname 'page-*' -path '*wp-content/themes*'

# 4. Confirm the traversal is actually blocked at the edge post-mitigation.
#    A 403/404 with NO OPML/RSS body is the pass condition.
curl -sk -o /dev/null -w '%{http_code} traversal probe\n' \
  'https://SITE/?page_id=1&pagename=templates%252f..%252f..%252fwp-links-opml'

# 5. Falcon sensor coverage - every WordPress host must have one, containers included.

Provenance: both dropped-payload filenames, both randomised-prefix patterns, both user agents, and every request marker in the behavioural block above appear verbatim in the saved source snapshots 01-patchstack.txt and 03-thehackernews.txt. The SHA256 row is a labelled placeholder because no hash has been published; it is deliberately not filled with a guess. Everything else in this appendix is a behavioural pattern, a configuration check, or context, not an atomic claim requiring its own source trace.

P1 · Web-server configuration, block pagename traversal at the edge

Apply on every reverse proxy and web server fronting WordPress, then reload. Test on one node before fleet rollout.

nginx

# /etc/nginx/snippets/cve-2026-87902-mitigation.conf
# 1. Block a pagename argument containing a traversal sequence, encoded or not,
#    in the query string. Covers single and double percent-encoding.
if ($arg_pagename ~* "(\.\.|%2e%2e|%252e%252e)") { return 403; }

# 2. The same check for pagename delivered in the POST body needs request-body
#    inspection (e.g. via ngx_http_lua_module or an AppSec/WAF component) -
#    nginx's own directives cannot filter POST body content natively. If you run
#    CrowdSec, its AppSec Component covers this out of the box via the
#    crowdsecurity/vpatch-CVE-2026-87902 rule (see N2 in Section 7).

# 3. Deny direct access to pearcmd.php at all three commonly reported paths,
#    belt-and-braces alongside removing the file per playbook P2.
location ~* /(usr/(local/lib|share)/php|usr/share/pear)?/?pearcmd\.php$ { deny all; return 403; }

# 4. Block the two published scanner/PoC user agents outright.
if ($http_user_agent ~* "(cve-2026-87902-poc|nuclei-cve-2026-87902)") { return 403; }

Apache 2.4

# /etc/apache2/conf-available/cve-2026-87902-mitigation.conf
RewriteEngine On

# Query-string pagename traversal, single or double encoded
RewriteCond %{QUERY_STRING} pagename=[^&]*(\.\.|%2e%2e|%252e%252e) [NC]
RewriteRule .* - [F,L]

# Deny direct access to pearcmd.php wherever it is reachable under the docroot
RewriteCond %{REQUEST_URI} pearcmd\.php [NC]
RewriteRule .* - [F,L]

# Block the two published scanner/PoC user agents
RewriteCond %{HTTP_USER_AGENT} (cve-2026-87902-poc|nuclei-cve-2026-87902) [NC]
RewriteRule .* - [F,L]

# POST-body pagename filtering needs mod_security or an equivalent request-body
# inspection module; Apache's rewrite directives alone cannot see the POST body.

Verify: nginx -t or apachectl configtest, reload, then run probe 4 from the Section 10 audit block. It must return 403 with no OPML/RSS content in the body.

P2 · PHP runtime hardening (php.ini / pool configuration)

; Add to php.ini or the relevant php-fpm pool .conf, then restart php-fpm.

; Breaks the pearcmd RCE escalation specifically: without argv populated from
; the query string, pearcmd.php cannot be driven via +config-show/+config-create
; even if it is included.
register_argc_argv = Off

; Confines PHP's own file access to the site root, which is the control that
; most directly addresses this vulnerability's root cause: even a successful
; get_page_template() traversal cannot open a file outside this path.
; Set per-vhost/per-pool, not just globally, so each site is confined to its
; own tree rather than a shared one.
open_basedir = /var/www/SITE_ROOT:/tmp

; Removes the specific functions this campaign's payloads use to turn a PHP
; include into a spawned shell. Audit for legitimate plugin usage first.
disable_functions = shell_exec,system,passthru,proc_open,popen

; Belt-and-braces: rename or remove pearcmd.php entirely rather than relying
; on runtime settings alone.
; mv /usr/local/lib/php/pearcmd.php /usr/local/lib/php/pearcmd.php.disabled
; mv /usr/share/php/pearcmd.php     /usr/share/php/pearcmd.php.disabled
; mv /usr/share/pear/pearcmd.php    /usr/share/pear/pearcmd.php.disabled

Verify: php -i | grep -E 'register_argc_argv|open_basedir|disable_functions' reflects the new values, then restart php-fpm and confirm the site still renders normally end to end (theme, uploads, any plugin that touches the filesystem).

P3 · Theme audit and pearcmd removal script

#!/usr/bin/env bash
# Run per site root. Read-only theme audit plus pearcmd removal (with backup).
set -euo pipefail
SITE_ROOT="/var/www/example-site"     # <-- set this

echo "[*] Themes with a top-level page-* directory (RCE precondition 1)"
find "${SITE_ROOT}/wp-content/themes" -maxdepth 2 -type d -iname 'page-*'

echo "[*] pearcmd.php presence at the three commonly reported install paths"
for p in /usr/local/lib/php/pearcmd.php /usr/share/php/pearcmd.php /usr/share/pear/pearcmd.php; do
  if [ -e "$p" ]; then
    echo "  found: $p -- backing up and removing"
    mkdir -p /var/backups/pearcmd-quarantine
    cp -p "$p" "/var/backups/pearcmd-quarantine/$(basename "$p").$(date +%Y%m%d%H%M%S)"
    chmod 000 "$p"
  fi
done

echo "[*] Done. Confirm your PEAR-dependent tooling, if any, still works before removing"
echo "    the quarantined copies permanently."

Pilot this one. A small number of hosting control panels and legacy PEAR-based tooling do call pearcmd.php for legitimate package management. Confirm nothing in your stack depends on it before removing it estate-wide; chmod 000 here is reversible, deletion is not.

P4 · Triage collection script (read-only)

#!/usr/bin/env bash
# Read-only evidence collection for a suspected CVE-2026-87902 compromise.
# Collects only, changes nothing. Run before any cleanup.
set -uo pipefail
SITE_ROOT="${1:-/var/www}"
OUT="/var/tmp/cve-2026-87902-triage-$(hostname)-$(date +%Y%m%d%H%M%S)"
mkdir -p "$OUT"

echo "[*] WordPress versions"
find "$SITE_ROOT" -name version.php -path '*wp-includes*' \
  -exec grep -H -m1 wp_version {} + | tee "$OUT/versions.txt"

echo "[*] PHP files in /tmp and /var/tmp changed since the day before disclosure"
find /tmp /var/tmp -maxdepth 2 -name '*.php' -newermt '2026-09-21' \
  -printf '%T+ %s %p\n' 2>/dev/null | sort | tee "$OUT/dropped-php.txt"

echo "[*] Exact and pattern-matched dropped filenames"
find /tmp /var/tmp -maxdepth 2 -regextype posix-extended \
  -regex '.*/(wp-pear-rce-flag|poc87902|luci_[A-Za-z0-9]+|zeta_[A-Za-z0-9]+)\.php' \
  2>/dev/null | tee "$OUT/named-dropped-php.txt"

echo "[*] pearcmd.php reachability"
for p in /usr/local/lib/php/pearcmd.php /usr/share/php/pearcmd.php /usr/share/pear/pearcmd.php; do
  [ -r "$p" ] && echo "READABLE: $p"
done | tee "$OUT/pearcmd-status.txt"

echo "[*] register_argc_argv setting"
php -i 2>/dev/null | grep -i register_argc_argv | tee "$OUT/php-config.txt"

echo "[*] Themes with a page-* top-level directory"
find "$SITE_ROOT" -maxdepth 4 -type d -iname 'page-*' -path '*wp-content/themes*' \
  | tee "$OUT/theme-precondition.txt"

echo "[*] Access-log hits"
grep -aEi 'pagename=[^ ]*(%2e%2e|%252e%252e|\.\.)|pearcmd|config-show|config-create|cve-2026-87902-poc|nuclei-cve-2026-87902' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
  | tee "$OUT/access-hits.txt"

echo "[*] Cron and SSH keys for the web user"
crontab -l -u www-data 2>/dev/null | tee "$OUT/webuser-cron.txt"
cat /var/www/.ssh/authorized_keys 2>/dev/null | tee "$OUT/webuser-authorized-keys.txt"

echo "[+] Collected to $OUT - preserve this before remediating."

Do not clean in place. The exploit writes attacker-controlled PHP outside the web root where routine web-root integrity tooling will never look, and the same primitive can be re-run to write somewhere more durable on a second attempt. Removing the one dropped file you found is not eradication if the precondition that let the attacker in is still standing. Rebuild from a known-good artefact and confirm the preconditions are closed (H3 through H6) before returning the host to service.

Honest read on this map. Three of the first four steps in the attack chain (reconnaissance, the pearcmd check, and the file write itself) have no endpoint coverage at all, and that is a property of the vulnerability rather than a shortfall in the queries: everything up to and including the write happens inside HTTP request handling, a domain an EDR sensor cannot see into. The pack is therefore strong from the moment the dropped payload actually executes onward, and blind before it. Two consequences follow. First, the web-log hunts in Section 7 are not optional garnish, they are the only coverage for the first half of the intrusion, and validation gate 6 (Section 11) is the highest-leverage item in the whole pack. Second, because Falcon cannot distinguish a probe that never got past the theme precondition from a request that never happened at all, a clean Q1 result on a host that was never patched proves only that the payload was never triggered successfully, not that the host was never targeted. Validation: gates 1 through 3 must pass before any result from this pack is trusted; gate 4 must complete before Q1, Q6 or Q7 are promoted to Detect.

The raw fetched text of every source above is saved in WordPress-CVE-2026-87902-RFI-Hunt-sources/ next to this file. No source contained instructions aimed at an automated agent, and no source was disqualified. Nothing in this pack was written from memory.