WordPress Core Page Template Local File Inclusion Leading to Remote Code Execution (Actively Exploited)

Summary

An unauthenticated path traversal vulnerability in WordPress core page-template resolution allows a remote attacker to make get_page_template() include an arbitrary readable local .php file from outside the active theme directories. On servers where additional preconditions are met, this escalates to remote code execution. The flaw affects every WordPress release from 4.7.0 through 7.1.1.

WordPress released 7.1.2 and backported fixes to all affected branches on 22 September 2026. Exploitation attempts began the same day, reconstructed from the patch diff. Within hours attackers had moved from reconnaissance to writing PHP files to disk, and by 23 September public scanning tooling, including a named Nuclei template, was in circulation. CISA added CVE-2026-87902 to the Known Exploited Vulnerabilities catalog on 25 September 2026.

Impact

Exploitability signals: CVSS 9.2 (Patchstack) · active exploitation including successful file writes · CISA KEV listed 25 September 2026 · unauthenticated, remote, no user interaction · public Nuclei template available.

The vulnerability has two tiers of impact. On any affected site, an attacker can include local PHP files, which leaks information and confirms the site is vulnerable. Remote code execution requires two further conditions: the active theme contains a top-level directory whose name begins with page- (such as page-templates), and PHP runs with register_argc_argv enabled on a host where PEAR’s pearcmd.php is installed. Where both hold, attackers abuse pearcmd.php to write attacker-controlled PHP to disk, which amounts to full code execution as the web server user.

Institutional WordPress estates tend to include many small, rarely maintained sites — departmental pages, event sites, student associations — running older branches on shared hosting stacks. Those are the most likely to meet the RCE preconditions and the least likely to have been updated.

Affected systems

WordPress core versions 4.7.0 through 7.1.1. Fixed releases are available on every affected branch:

• 7.1.x — fixed in 7.1.2
• 7.0.x — fixed in 7.0.6
• 6.9.x — fixed in 6.9.9
• 6.8.x — fixed in 6.8.10
• Older branches back to 4.7 — fixed in the corresponding backport release, down to 4.7.37

Indicators of compromise

Patchstack has published the following signals from observed attack traffic. Traversal payloads arrive percent-encoded and vary in depth, case and HTTP method, so detection should not anchor on a single exact string.

• A pagename parameter, in the query string or POST body, containing %2e%2e or %252e%252e
• A pagename value beginning with templates%2f or another page- directory name
• pagename and page_id appearing together in requests to the site root or /index.php
• Any request containing pearcmd, +config-show, or +config-create
• User agents cve-2026-87902-poc/1.0 or nuclei-cve-2026-87902/1.0 (most attack traffic spoofs browser user agents, so absence proves nothing)
• Unexpected .php files in /tmp or /var/tmp, including names such as wp-pear-rce-flag.php, poc87902.php, luci_<random>.php, or zeta_<random>.php
• OPML or RSS output returned with an HTTP 200 from an ordinary page URL, which indicates a reconnaissance probe succeeded Attack traffic originates from several hundred source addresses, so IP blocklisting is not an effective control.

Action

1. Update every WordPress installation to the fixed release on its branch. Check the installed version on each site directly rather than assuming automatic background updates have applied the fix.
2. Inventory your WordPress estate. Include departmental, event, research-group, and student-run sites, as well as sites hosted by third parties on the institution’s behalf. Unmaintained sites are the highest-risk population for this vulnerability.
3. Hunt through access logs and hosts for the indicators listed above, going back to 22 September 2026. Pay particular attention to POST requests: WordPress reads pagename from the POST body in preference to the query string, and POST has become the dominant method in attack traffic.
4. Treat a host as compromised if unexpected .php files are present in /tmp or /var/tmp, or if logs show requests containing +config-create that returned successfully. Isolate the host, preserve logs and files for investigation, rebuild from a known-good source, and rotate the database credentials and secret keys in wp-config.php along with all administrator passwords.
5. If you cannot update immediately, block requests whose pagename parameter contains traversal sequences at the web server or WAF; legitimate page slugs never contain them. Separately, disable register_argc_argv in the PHP configuration. This does not fix the file inclusion but breaks the pearcmd.php path to code execution. Neither measure replaces the update.
6. Report suspected compromise. Institutions that find matching indicators should report the incident so we can correlate activity across the constituency.

Think a system in the community is affected or compromised?Report an incident