Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.

CVE-2026-87902: WordPress LFI & RCE

CVSS · High

8.1

In CISA KEV

Yes

Published

Oct 17

CVE explainers 2026-10-17 10 min read

Security Research Desk Source-checked

Auto-checked against the official CVE record · Human-reviewed after publishing · Updated 2026-10-17

⚠

CISA Known Exploited Vulnerability

Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-09-25. Federal agencies must patch by 2026-09-28.

Everything CISA added on 2026-09-25

Threat Intelligence

2GitHub refs

▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.

CISOBrief · 30-second brief

TL;DR - CVE-2026-87902 lets unauthenticated attackers influence WordPress page-template resolution to include readable local PHP files. - WordPress 4.7.0 through 7.1.1 is affected; upgrade to the fixed release for your branch or the latest available version. - CISA lists the vulnerability in KEV, confirming exploitation in the wild, and public PoC code is available.

AnalystImpact · assess the risk

Are You Affected?

CVE-2026-87902 is a critical WordPress vulnerability affecting WordPress Core installations from 4.7.0 through 7.1.1. The vulnerability is reachable over the network without authentication, but remote code execution is conditional. Even without the specific server and active-theme prerequisites for RCE, a vulnerable site remains exposed to local file inclusion.

Field	Value
CVE ID	CVE-2026-87902
NVD CVSS	8.1 High
Public advisory CVSS	9.2 Critical, CVSS 4.0
Attack vector	Network
Authentication / privileges	None required
User interaction	None required
Core issue	Local PHP file inclusion through page-template resolution
RCE	Conditional on server and active-theme prerequisites
Patch available	Yes
CISA KEV status	Yes, added 2026-09-25

The affected release range includes WordPress 4.7.0 through 7.1.1. Reported affected branches include 7.1.0–7.1.1, 7.0.0–7.0.5, 6.9.0–6.9.8, 6.8.0–6.8.9, and 6.7.0–6.7.8, with corresponding vulnerable releases in maintained branches back to 4.7.36. Treat any installation below the applicable fixed version as vulnerable unless WordPress or the relevant security advisory confirms otherwise.

Branch-specific fixes reported for this issue include WordPress 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, and 6.0.16. Security backports reportedly continue through 4.7.37. Maintenance support and release availability can change, so the preferred target is the latest supported WordPress release rather than an old branch-specific patch.

Analyst’s Take: Patch first, then investigate. KEV inclusion, public PoCs, and unauthenticated network reachability make exposure urgent even though RCE depends on server and active-theme conditions.

The Fix, If You’re in a Hurry

Upgrade immediately to the latest available WordPress release. If operational constraints require staying on a maintenance branch, use the fixed version for that branch, such as 7.1.2 for the 7.1 branch, 7.0.6 for the 7.0 branch, or 6.9.9 for the 6.9 branch. Sites on older branches should use the corresponding fixed release listed above, where available, and should plan a broader upgrade to a supported version.

For administrators using WP-CLI, an upgrade can be performed with a command such as the following after taking a backup and confirming that the target version is appropriate for the site:

wp core update --version=7.1.2 --force
wp core update-db
wp core version

Replace 7.1.2 with the fixed version for the deployed branch or, preferably, the latest supported release. Validate the result with wp core version, confirm that the web application is serving the expected files, and review error logs after the update. Package-managed or hosting-managed WordPress installations should use the provider’s supported update mechanism instead.

If patching cannot be completed immediately, reduce exposure by restricting public access at the reverse proxy, load balancer, firewall, or hosting control plane. A WAF rule that blocks traversal sequences, encoded traversal, and suspicious template parameters may reduce opportunistic traffic, but it is not a substitute for upgrading. Disabling a single theme or plugin does not remove the Core vulnerability unless testing and vendor guidance demonstrate that the vulnerable code path is no longer reachable.

Administrators should also protect WordPress accounts with unique credentials and multi-factor authentication where available. A password manager such as Try 1Password → can help teams generate and store unique administrator passwords, although credential hygiene does not fix this unauthenticated WordPress Core vulnerability.

Technical Notes: Immediate Mitigation

A temporary access-control example for an Apache deployment might restrict the site to an approved administrative network while patching is underway:

<Location />
    Require ip 192.0.2.0/24
</Location>

This is an exposure-reduction example and must be adapted to the actual application architecture. Avoid deploying a configuration that blocks legitimate users without a tested rollback plan. After patching, remove temporary restrictions only after confirming the running WordPress version and reviewing the site for compromise.

How This Vulnerability Works

The vulnerable behavior is associated with WordPress page-template resolution in get_page_template(). The affected logic could construct a page-template candidate from attacker-influenced input without adequately preserving the expected boundary of the active theme directory. An attacker could therefore cause WordPress to resolve a path outside the intended theme location and include a readable local .php file.

This is a local file inclusion and path traversal issue associated with CWE-98 and CWE-22. It is not inherently a remote file inclusion vulnerability in the sense of fetching arbitrary PHP from an attacker-controlled URL. The relevant file must be present and readable on the server, and WordPress must process the attacker-controlled input through a reachable template-resolution path.

The exploitation chain generally requires a publicly reachable WordPress site, a vulnerable Core version, a request path that reaches the affected resolution logic, and a readable local PHP file located where traversal can reach it. Escalation to RCE depends on additional server and theme conditions. Public reproduction material describes a lab chain involving pearcmd.php, PEAR configuration functionality, writing a PHP payload, and subsequently including that payload. That chain is environment-dependent; it does not show that every vulnerable WordPress site is immediately remotely executable.

Technical Notes: Root Cause and Exploitation Conditions

The practical distinction for defenders is:

Attacker-controlled template input
        |
        v
Insufficient theme-directory boundary enforcement
        |
        v
Readable local PHP file included by WordPress
        |
        +--> File disclosure or application-side effects
        |
        +--> Conditional PHP execution and RCE
             when server/theme prerequisites are satisfied

Do not test public systems with exploit payloads unless the owner has authorized the activity. The public repositories associated with this CVE describe vulnerable lab environments and should be reviewed as threat intelligence and detection references, not executed against production sites.

Severity, Explained

The NVD assigns CVE-2026-87902 a CVSS score of 8.1 High, but the supplied NVD response does not include the underlying vector. A separate public advisory reports a 9.2 Critical score under CVSS 4.0 with this vector:

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

The scores differ because they come from different scoring sources and methodologies. Organizations should record both where required by their vulnerability-management process, but operational prioritization should reflect the stronger evidence: the issue is unauthenticated, network-reachable, publicly documented, and listed in CISA KEV.

The advisory vector indicates network attack access (AV:N), low complexity (AC:L), and no privileges or user interaction (PR:N and UI:N). It also includes an attack prerequisite (AT:P), reflecting the environmental and application conditions needed for the complete impact. The high confidentiality, integrity, and availability impact values describe the potential consequences when the RCE path is successfully achieved.

In practice, “conditional RCE” should not be interpreted as low risk. An attacker does not need an authenticated WordPress account, and the local file inclusion can provide a stepping stone for compromise. Internet-facing sites below the fixed release should be treated as urgent remediation candidates, particularly where PHP utilities, writable directories, unusual themes, or weak filesystem isolation are present.

For broader application security context, review the OWASP Top 10 overview and map the issue to your organization’s existing web-application risk controls.

Is It Being Exploited?

Yes. CISA lists CVE-2026-87902 in its Known Exploited Vulnerabilities catalog, with an addition date of 2026-09-25 and a remediation due date of 2026-09-28. KEV inclusion confirms exploitation in the wild. CISA’s field for known ransomware campaign use is Unknown; that means ransomware association has not been established in the supplied record, not that exploitation is unconfirmed.

Reporting linked to Patchstack describes attackers probing WordPress sites shortly after the patch was released. This is consistent with rapid internet scanning and exploit validation activity against exposed installations. An unpatched public site may therefore already have received malicious requests, even if there is no evidence of successful code execution.

Public proof-of-concept material is available. The identified repositories include ressl/cve-2026-87902-poc and dinosn/cve-2026-87902-wordpress-lfi-lab, the latter describing a reproduction lab, scanner, and PoC for the reported affected range. Public PoCs lower the effort required for opportunistic exploitation and increase the importance of retrospective log and filesystem review.

ResponderRunbook · act now

Detecting It in Your Environment

Start with the web server, reverse proxy, WAF, PHP, and WordPress logs covering the period before patching. Look for requests containing traversal attempts, repeated or double URL encoding, unexpected page-template or pagename parameters, and references to local PHP utilities such as pearcmd.php. A single suspicious request is not proof of compromise. Repeated requests followed by new PHP files, unusual outbound connections, or administrative changes should be escalated as a potential incident.

Inspect the host and WordPress installation for recently created or modified PHP files, unexpected changes under wp-content/themes, unauthorized administrator accounts, modified scheduled tasks, unfamiliar plugins, and web-shell behavior. Check file modification times against deployment records and compare Core, theme, and plugin files with known-good copies. Exploitation can produce effects outside WordPress’s normal content directories, so review the broader webroot and PHP-readable filesystem paths.

If an investigation finds suspicious administrator activity or reused credentials, rotate affected secrets and review other services that used the same passwords. Password reuse can expand the impact of a WordPress compromise beyond the original site.

Technical Notes: Log Patterns and Queries

A basic shell search for likely traversal and target indicators can help triage compressed or plain-text access logs:

grep -Eai \\
'\\.\\.%2f|%2e%2e%2f|%252e%252e|pearcmd\\.php|pagename=|page[-_]?template|wp[-_].*(template|page)' \\
/var/log/nginx/access.log /var/log/apache2/access.log

A Splunk-style query for common indicators might look like:

index=web
| regex uri="(?i)(\\.\\.|%2e|%252e|pearcmd\\.php|pagename=|page[-_]?template)"
| stats count values(uri) values(http_user_agent) by src_ip, host, status
| sort - count

These patterns are intentionally broad and will produce false positives. Normalize and decode URLs before matching where the logging pipeline permits it, while retaining the original request URI for forensic review. Correlate suspicious requests with response status, response size, PHP process activity, file creation events, and subsequent requests to newly created files.

References and Further Reading

The primary technical and remediation references are the NVD record and the WordPress GitHub Security Advisory. The NVD entry provides the vulnerability description and NVD score, while the WordPress advisory is the authoritative source for project-specific remediation information.

CISA’s KEV catalog entry should be incorporated into vulnerability-management and incident-response workflows. Because this CVE is KEV-listed, organizations subject to applicable CISA guidance should follow the relevant patching, exposure-assessment, and forensic-triage requirements.