Critical WordPress Vulnerability CVE-2026-87902: Update Your Website Now
WordPress has released security updates for CVE-2026-87902, a critical vulnerability in WordPress core. The project advises site owners to update immediately. The issue can potentially allow an unauthenticated attacker to execute a PHP file already present on the server, but the risk is conditional: successful exploitation requires a particular theme directory structure, a readable local PHP file at a predictable location, and a compatible server and PHP configuration [1][2].
That qualification matters. Not every unpatched WordPress site is automatically compromised, and the advisory does not establish that every environment is exploitable. However, a critical core flaw should not be left unresolved while an administrator tries to prove that every required condition is absent. The practical response is to back up the site, install the appropriate patched WordPress release, verify the deployment, and review the surrounding hosting environment.
September 25 Update: CISA Confirms Active Exploitation
On September 25, 2026, the U.S. Cybersecurity and Infrastructure Security Agency added CVE-2026-87902 to its Known Exploited Vulnerabilities Catalog. That listing means CISA has evidence that the vulnerability has been exploited in the wild; it does not establish how widespread the activity is or that every unpatched site is exploitable [3].
CISA lists September 28, 2026 as the remediation due date for covered federal civilian executive branch agencies under its directive. That is not a universal deadline for private businesses. For small and midsized organizations, the operational signal is to treat this as an exploited vulnerability: confirm the production version, install the appropriate fixed release promptly under normal change control, preserve relevant logs, and review exposed systems for suspicious file changes, administrator accounts, scheduled tasks, redirects, and web or PHP activity.
CISA also marks forensic triage as required for the federal response. Website owners should not interpret a successful update as proof that no earlier exploitation occurred. If a site was internet-facing while vulnerable—especially if it has unexplained changes or incomplete logs—preserve evidence and escalate to incident-response review rather than simply reinstalling files.
What CVE-2026-87902 Affects
The vulnerability is a path-traversal issue in the WordPress core get_page_template() function. According to the WordPress security advisory, an unauthenticated attacker may be able to manipulate a theme-related path so that WordPress includes a local PHP file. If the attacker can identify a suitable readable PHP file and the server processes it in the necessary way, the result could be remote code execution [2].
Remote code execution is serious because it can give an attacker a route to run commands or application code on the affected system. Depending on the hosting configuration and the privileges available to the web process, that could lead to website modification, data exposure, persistence, or use of the server as a foothold for additional activity.
The official advisory rates the issue Critical with a CVSS score of 9.2. It identifies supported fixed releases across multiple WordPress branches, from 4.7.37 through 7.1.2 [2]. Administrators should not assume that being on an older long-lived branch removes the need to patch; instead, confirm that the exact installed version is one of the fixed releases listed by WordPress.
Why Exploitability Is Conditional
A severity rating describes potential impact and exploit characteristics, not proof that every installation can be exploited in exactly the same way. For CVE-2026-87902, the official advisory describes several conditions that influence practical exposure [2]:
- The active child or parent theme must contain a top-level directory whose name begins with
page-, such aspage-templates. - A local PHP file must exist at a location the attacker can predict and the WordPress process can read.
- The server and PHP configuration must handle the included file in a way that produces executable behavior.
These conditions may reduce exposure on some systems, but they are not a safe substitute for patching. Website owners may not have a complete inventory of files placed by themes, plugins, hosting tools, backups, control panels, or prior administrators. Configuration also changes over time. Updating removes the known vulnerable behavior instead of relying on assumptions about the rest of the environment.
Which WordPress Versions Should Be Updated?
WordPress 7.1.2 is the current security release for the 7.1 branch. The WordPress project also published security releases for supported older branches. The authoritative list of fixed versions is maintained in the WordPress release announcement and security advisory [1][2].
As a simple rule, if your site is not running 7.1.2 or a corresponding fixed release for its supported branch, schedule the update now. If an older branch is retained for compatibility reasons, document why it remains necessary and confirm that it has received the branch-specific security release. Unsupported WordPress versions should be upgraded to a supported version rather than treated as safely patched.
To check the installed version, sign in to the WordPress administrative dashboard and review Dashboard → Updates. Managed WordPress customers can also verify the deployed version in their hosting control panel or ask their provider for written confirmation. Do not rely only on a cached public page or a scanner result; verify the actual production installation.
A Safe Update and Verification Checklist
1. Create a recoverable backup
Back up the WordPress database and the complete site files before changing production. Confirm where the backup is stored, how long it is retained, and who can restore it. A backup that has never been tested is useful evidence, but not yet a proven recovery path.
2. Record the current state
Capture the installed WordPress version, active theme, critical plugins, PHP version, and any known compatibility constraints. Note whether automatic core updates are enabled. This creates a baseline for troubleshooting and helps distinguish an update problem from a pre-existing issue.
3. Apply the official security release
Use the WordPress dashboard, WP-CLI, or your managed hosting workflow to install WordPress 7.1.2 or the appropriate branch-specific fixed release. Obtain updates through WordPress or your established hosting-management channel. Avoid unofficial packages or download links shared through email and social media.
4. Verify the deployed version
After the update completes, confirm the version from the production dashboard or command line. Clear application, page, object, and CDN caches where appropriate, then verify that the public website and administrator login still work. Check several representative pages, forms, search, ecommerce or booking functions, and other business-critical workflows.
5. Review logs and file integrity
Examine web, PHP, security-plugin, and hosting logs for unusual requests, new administrator accounts, unexpected file changes, or unexplained scheduled tasks. Compare WordPress core files with known-good copies using your management platform or wp core verify-checksums when WP-CLI is available. A clean update does not prove that no earlier activity occurred, so investigate anomalies rather than simply deleting them.
6. Review themes and unnecessary code
Remove themes and plugins that are no longer needed, while retaining an appropriate fallback theme if your operating procedure requires one. Update the active theme and plugins, restrict file-editing and administrative access, and confirm that production file permissions follow your hosting provider’s guidance. Reducing unused code narrows the number of files and paths that must be maintained.
7. Confirm monitoring and recovery
Make sure uptime checks, security alerts, backups, and log retention are functioning after the update. Record the completion date, deployed version, person responsible, tests performed, and any exceptions. For business-critical sites, schedule a restore test rather than waiting for an incident to reveal a recovery problem.
If You Cannot Update Immediately
Treat delay as a temporary exception, not a mitigation strategy. Restrict administrative access, preserve logs, confirm that backups are current, and ask the hosting provider or WordPress maintainer to assess the environment against the conditions in the official advisory. A web application firewall may reduce some malicious traffic, but it does not remove the vulnerable code and should not be represented as an equivalent fix.
If there are signs of compromise—unexpected administrators, changed PHP files, redirects, unfamiliar scheduled tasks, suspicious outbound traffic, or unexplained resource usage—preserve evidence and begin incident response. Updating alone may close the vulnerability without removing persistence that was established earlier.
The Practical Takeaway
CVE-2026-87902 deserves prompt action because it affects WordPress core and carries potentially severe impact. It also deserves precise communication: the potential code-execution path depends on additional theme, file, and server conditions, and CISA has now confirmed exploitation by adding it to the Known Exploited Vulnerabilities Catalog. The available primary sources do not quantify how widespread that activity is.
For most organizations, the correct decision is straightforward: back up the site, update to WordPress 7.1.2 or the appropriate fixed branch release, verify the production deployment, and review logs and file integrity. Reliant System can help businesses validate WordPress updates, review hosting and security controls, and establish a repeatable patch-and-recovery process.