CVE-2026-87902: WordPress Core Remote File Inclusion Vulnerability

Overview

CVE-2026-87902 is a remote file inclusion weakness in WordPress Core. In plain terms, an unauthenticated attacker can influence how WordPress resolves page templates so that a readable local .php file outside the active theme directories is included, which can lead to remote code execution on the server.

This matters because WordPress powers a large share of public websites. Unauthenticated reach plus a path to code execution raises the risk of full site compromise, defacement, malware hosting, or further lateral movement. Confirm exact scope, fixed releases, and configuration notes against the vendor advisory before acting.

How it works

The reported weakness is aligned with CWE-98 (improper control of filename for include/require-style operations). WordPress resolves which template file to load for a given request. When that resolution can be steered to include a chosen local readable .php path outside the active theme directories, PHP executes that file in the application context.

An attacker who can trigger the vulnerable template-resolution path without authentication may cause inclusion of an unintended local PHP file. If that file contains (or can be arranged to contain) attacker-controlled logic, the outcome is remote code execution under the web server or PHP process identity. Public detail on exact request parameters, file-selection constraints, and preconditions is limited; treat mechanics as class-level and verify against the official WordPress security advisory.

• Flaw class: remote/local file inclusion via template resolution (CWE-98).
• Access: described as unauthenticated.
• Impact path: include of a chosen readable local .php outside active theme dirs → possible RCE.
• Do not assume arbitrary remote URL inclusion or specific payloads unless the vendor advisory states them.

Am I affected? How to find it in your systems

WordPress Core typically runs as PHP behind a web server (Apache, Nginx, or similar), on self-hosted VMs, shared hosting, containers, or platform-as-a-service. Inventory every property that serves WordPress, including staging, multisite networks, and forgotten marketing sites.

• Enumerate installs: package inventories, configuration-management facts, container images, host filesystem paths that contain wp-includes, wp-admin, and wp-config.php, and CMS discovery in external attack-surface scans.
• Record Core version (and whether auto-updates are enabled) from the site admin UI, WP-CLI (core version), or version files—then compare to the fixed versions named in the vendor advisory. Do not rely on version numbers from secondary sources.
• Note multisite, custom theme layouts, reverse proxies, and whether the site is internet-exposed; CISA guidance stresses evaluating each asset’s internet exposure.
• Telemetry: unusual template or PHP include errors, requests that manipulate template-related parameters, unexpected execution of PHP files outside normal theme/plugin paths, new or altered PHP files, anomalous outbound connections from the web pool, and integrity failures on Core files. Absence of known public exploit signatures does not prove safety.

If you cannot confirm the patched state from the vendor advisory, treat internet-facing instances as in-scope until proven otherwise.

How to remediate

Patch first. Apply the WordPress Core update specified in the official vendor advisory for CVE-2026-87902, following your normal change process and CISA’s direction to apply mitigations per vendor instructions and BOD 26-04 risk-based prioritization.

• Upgrade Core on all installs (production and non-production) to the fixed release(s) named by WordPress; verify version after deploy.
• Where auto-updates are used, confirm they completed and that the running code matches the advisory.
• After patching, re-check file integrity for Core, review admin and plugin/theme changes, and rotate credentials if compromise is suspected.
• Hardening for this class: keep Core, themes, and plugins minimal and current; restrict filesystem permissions so the web user cannot write arbitrary PHP under web roots; disable unused PHP handlers; limit which paths the application can include; run the site as a least-privilege user; and separate sites so one compromise does not share a PHP pool with others.
• If mitigations are unavailable for a given deployment, follow CISA’s BOD 26-04 path for cloud or discontinue use of the product as applicable.

If you can't patch immediately

Compensating controls reduce—but do not eliminate—risk until the vendor fix is applied.

• Reduce exposure: place the site behind VPN or IP allowlists where business-viable; remove unnecessary public access to admin and unused endpoints.
• Network segmentation: isolate the WordPress host from internal databases and high-value networks; egress-filter the web tier.
• Virtual patching / WAF: if your WAF vendor offers rules for this CVE or for WordPress template-inclusion abuse, enable them in blocking mode after testing; treat this as temporary.
• Feature and config tightening: disable unused template or theme-switching features if your deployment allows; ensure themes/plugins cannot be written by untrusted roles; enforce strict open_basedir or equivalent path limits where operationally sound—confirm side effects in staging.
• Monitoring: heighten alerts on PHP errors tied to includes, web shells, new .php files outside expected directories, and privilege changes; preserve logs for forensics per your and CISA’s triage expectations.
• Plan the mandatory Core upgrade; compensating controls are not a substitute for the vendor patch.

If your data may have been exposed

Actively exploited remote-code-execution flaws in CMS platforms frequently precede full site takeover and data theft, even when ransomware use is not documented for this CVE. If exploitation is plausible, follow incident procedures: isolate, preserve evidence, rotate secrets, audit content and user accounts, and notify stakeholders as required.

You can run a free exposure scan of your email addresses against known breach datasets to see whether associated credentials or personal data already appear in public breach collections, and then force password resets and enable multi-factor authentication where accounts may be reused.