Summary

CVE-2026-87902 is a critical, unauthenticated flaw in WordPress core, rated CVSS 9.2 (CWE-98, PHP file inclusion). By sending a specially encoded path in a page request, an attacker can trick the get_page_template() function into loading a PHP file from outside the theme folder, and where the server and active theme meet a few common conditions, that becomes full remote code execution with no login required. It affects a wide range of WordPress versions, from 4.7.0 to 7.1.1.

There is no named group behind CVE-2026-87902: attackers reverse-engineered the fix as soon as WordPress shipped version 7.1.2 and started scanning the same day, quickly moving from simple checks to writing malicious PHP onto vulnerable servers. With a public exploit tool already circulating, any WordPress site that meets the preconditions should be treated as at risk of full compromise.

Affected Products

CVE

Vulnerability Details

1. #01

   At its core, CVE-2026-87902 is a PHP file inclusion flaw (CWE-98) hiding inside WordPress's page-template logic. Attackers wasted no time with it: within hours of WordPress going public with the vulnerability, live sites were already being probed and hit. When WordPress builds a page, get_page_template() decides which template file to load based on the page's slug. WordPress runs that slug through its own sanitiser first, and that sanitiser was written to preserve percent-encoded characters while stripping literal dots and slashes. That gap is the whole problem, path is blocked, but a percent-encoded version survives the sanitiser and is then decoded, letting the template path climb out of the theme directory and point at any readable .php file on the server.

2. #02

   To pull this off, an attacker sends a request that pairs a valid page_id with a crafted pagename value. The page_id matters, because without a real page WordPress returns a 404 and the vulnerable code never runs, which is also why the two parameters appearing together is such a useful detection signal. The pagename value usually begins with a real directory starting with page- (such as page-templates), then uses the encoded traversal to reach a target file. The favourite target is PHP's pearcmd.php.

3. #03

   When the server has register_argc_argv enabled, the query string is handed to the included script as command-line arguments. An attacker first sends +config-show to confirm the trick works, then switches to +config-create to write a file of their choosing, arbitrary PHP with attacker-controlled content, which is code execution. Observed activity drops these files into /tmp and /var/tmp; some are harmless proof-of-concept markers, while others plant a tag that runs a shell command or pulls in a web shell.

4. #04

   The vulnerability affects WordPress core versions 4.7.0 through 7.1.1, an unusually long range that reaches back years. The "attack requirements present" element reflects the two preconditions: the active theme must have a top-level directory whose name starts with page-, and a suitable readable .php target (such as pearcmd.php) must exist on the server. This is not theoretical, the first exploitation attempts hit sensors at 11:49 UTC on 22 September 2026, the very day the patch shipped, showing the payloads were built straight from the patch diff. By that afternoon the activity had moved from probing to writing files to disk, and by 23 September a named Nuclei template was circulating and traffic had spiked, with independent honeypot telemetry recording dozens of attempts inside the first day.

Vulnerability

Recommendations

1. 01
   Update WordPress Immediately

   Apply WordPress 7.1.2 right away, or the patched release for your branch, 7.0.6, 6.9.9, 6.8.10, and backports reaching all the way to 4.7.37. This is the only complete fix for CVE-2026-87902, and with active exploitation under way it should be treated as urgent rather than as routine maintenance.

2. 02
   Hunt for Signs of Compromise

   Check /tmp and /var/tmp for unexpected .php files, including names like wp-pear-rce-flag.php, poc87902.php, and files beginning with luci_ or zeta_. Search web logs for a pagename value containing %2e%2e or %252e%252e, a pagename beginning with templates%2f, pagename and page_id appearing together, or any request mentioning pearcmd, +config-show, or +config-create. If a normal page URL ever returned OPML or RSS content, treat that host as successfully probed and investigate it as potentially compromised.

3. 03
   Apply Temporary Mitigations If You Cannot Patch Yet

   If an immediate update is not possible, block requests where the pagename parameter contains traversal sequences; a genuine page slug never does, so this can be filtered without affecting normal traffic. Disabling PHP's register_argc_argv setting does not fix the inclusion itself, but it breaks the pearcmd chain, downgrading potential code execution to a lower-impact information leak.

4. 04
   Harden the PHP Environment

   Remove or restrict PEAR and pearcmd.php on production web servers where they are not needed, since they are the primary springboard from file inclusion to full code execution. Run the web server under a least-privilege account so that even a successful inclusion has limited reach.

5. 05
   Vulnerability Management

   Maintain an accurate inventory of your WordPress installations and their versions, keep automatic updates enabled, and place a virtual patching or web application firewall layer in front of internet-facing sites so newly disclosed flaws can be blocked quickly while patches roll out. Review the security posture of third-party themes and plugins regularly as part of this process.

Indicators of Compromise (IoCs)

MITRE ATT&CK TTPs

References & Patch Links

Patch Link

• WordPress Releaseshttps://wordpress.org/download/releases/

References

• https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp
• https://patchstack.com/articles/cve-2026-87902-attackers-started-probing-wordpress-sites-hours-after-the-patch/