CVE-2026-87902 Added to CISA KEV; WordPress Fixes Available

CISA's KEV Listing Puts WordPress CVE-2026-87902 on the Federal Priority List​

CISA's alert says it has added one new vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog, based on evidence of active exploitation. The entry is titled "CVE-2026-87902 WordPress Core Remote File Inclusion Vulnerability". CISA adds that this type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise.

The KEV Catalog is CISA's list of vulnerabilities with confirmed real-world exploitation. The published alert gives no remediation due date and no mitigation specific to this CVE beyond what the catalog normally implies, so readers should not assume a particular federal deadline. The underlying facts about the flaw come from the WordPress project, which published its advisory, GHSA-7hp8-65ch-5whp, alongside WordPress 7.1.2.

Some reporting from the same week says CVE-2026-87902 was not yet in the catalog. Tech Times, for example, wrote that the flaw has not yet been added to the CISA KEV catalog as of September 25, 2026. CISA's own alert dated September 25 overrides those earlier reports. The bug is listed now.

Inside CVE-2026-87902: A Path Traversal in get_page_template()​

WordPress describes the bug as an unauthenticated path traversal in page-template resolution. According to the project's advisory, an attacker who does not need to log in can make the get_page_template() function include a readable local .php file of the attacker's choosing, even when that file sits outside the active theme's directories. The weakness is classified as CWE-98, improper control of a filename used in a PHP include or require statement.

CISA's entry calls the bug "remote file inclusion," which can mislead anyone scoping the risk. That label follows the formal CWE-98 title, which reads "PHP Remote File Inclusion." What WordPress actually documents is the inclusion of a file that already exists on the server, not code fetched from an attacker's machine. Threat trackers such as Previdian describe it more precisely as Unauthenticated Local File Inclusion (conditional RCE).

The fix is small. WordPress's version documentation for 7.1.2 lists one revised file, /wp-includes/template.php, and no revised packages. A patch that small can be applied quickly. It also makes the patch diff easy for attackers to study, which is what happened next.

SOCFortress has analyzed the attack traffic. It says the exploit relies on tricking the get_page_template() function into loading files outside the intended theme directory by manipulating internal WordPress parameters, and that a successful exploit requires the concurrent use of pagename and page_id. Previdian's record shows the observed request shape as an unauthenticated GET request that combines page_id with a pagename value containing an encoded path separator.

The Theme and PHP Conditions That Turn CVE-2026-87902 Into RCE​

WordPress rates the flaw Critical, with a CVSS v4 score of 9.2. The vector string lists Attack Requirements as "Present," and that detail matters most for judging real exposure. The advisory states that remote code execution is possible only if relevant preconditions are met for both the server environment and the active theme.

The first precondition is in the theme. The active child or parent theme must contain a top-level directory whose name starts with page-, such as page-templates. WordPress says this is true of the legacy Twenty Twelve and Twenty Fourteen themes and of some popular third-party themes, including Neve, Hestia, and Sydney.

The second precondition is on the server. A local .php file that the attacker picks must exist and be readable by the web server account. WordPress names the well-known pearcmd.php technique, which turns PEAR's command script into code execution when PHP's register_argc_argv setting is On. The advisory says the official PHP image for Docker is affected, and that the default cPanel configuration is affected when running PHP versions earlier than 8.5.

Both conditions are common in real hosting. Tech Insider's reporting that every WordPress site is potentially affected regardless of which plugins are installed, unless the Core software itself has been updated holds for the file-inclusion bug itself, because it sits in core rather than in a plugin. Full takeover through pearcmd.php, however, needs both conditions. The advisory is clear, though, that the file-inclusion step works without authentication on any unpatched site. Administrators should treat the RCE conditions as a guide for investigating possible compromise, not as a reason to delay patching.

Patchstack's Timeline Shows Exploitation Began the Day WordPress 7.1.2 Shipped​

As first reported by The Hacker News, threat actors have begun to actively exploit a critical security flaw in WordPress within hours of public disclosure. The earliest data point comes from security firm Patchstack, which recorded the first exploitation attempt at 11:49 UTC on September 22, 2026, the same day WordPress shipped version 7.1.2 and a wave of backported patches to older branches.

The attacks escalated quickly. Tech Times, citing Patchstack, reports that by September 23, Patchstack confirmed that attack traffic had surged more than tenfold in volume and that payloads had escalated from passive reconnaissance to writing executable PHP files to disk. Previdian's separate honeypot data recorded 68 exploitation attempts beginning September 23, and SOCFortress describes the same progression: attackers initially probed vulnerable sites using standard core files before escalating their tactics to abuse pearcmd.php for remote code execution and arbitrary file creation.

The number of exposed sites is large. According to Tech Times, more than 350,000 sites remain exposed, according to Shadowserver. No other outlet in this research independently reported that Shadowserver figure, so treat it as a single-source estimate of scale, not a verified count.

SOCFortress explains the speed this way: the attackers successfully reverse-engineered the patch diff to identify the "sink" and develop functional payloads. Since the fix touched only template.php, that explanation fits the facts, though it remains the firm's analysis and not a confirmed account of how the attackers worked. For defenders, the result is the same either way. For this bug, the gap between the patch and the first attacks was measured in hours.

Matching Every WordPress Branch to Its Fixed Release​

WordPress backported the fix, in the project's words, as a courtesy to all branches still eligible for security fixes, which currently means back to 4.7. The project also reminds users that only the most recent version is actively supported. WordPress 4.6 and earlier get no security updates at all, so sites on those versions have to move to a supported release. They cannot be patched where they are.

WordPress's 7.1.2 release post gives two ways to update. Administrators can download the release from WordPress.org, or open the WordPress Dashboard, click Updates, and then click Update Now. The post also says that on sites supporting automatic background updates, the update process will begin automatically. "Will begin" is not the same as "has finished." Hosting restrictions, file permissions, or disabled auto-updates can leave a site unpatched, so confirm the installed version on each site yourself.

Some vulnerability trackers show a different severity score. A VulnRadar alert generated on September 24 lists a CVSS score of 8.1, and Previdian labels the flaw High 8.1. WordPress, as the CVE's issuing authority, assigns 9.2 under CVSS 4.0. If your scanner shows 8.1, it is probably using a different scoring source. Either score is high enough to demand immediate action once the flaw is on the KEV list.

What BOD 26-04 Requires and What It Asks of Everyone Else​

CISA's alert ties the listing to Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," which establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. CISA issued the directive on June 10, 2026. It combined and replaced BOD 19-02, which covered internet-accessible systems, and BOD 22-01, the directive that originally created KEV deadlines.

BOD 26-04 ranks patching work by four factors: how exposed the asset is, whether the flaw is on the KEV list, whether exploitation is automated, and what an attacker can do after exploitation. CISA's alert says the directive puts particular urgency on KEV-listed CVEs on publicly exposed assets where exploitation grants total control. It also sets out when agencies must check whether an attacker compromised a system before the patch went in. An internet-facing WordPress server with a chain to RCE fits that description closely.

The directive legally binds only FCEB agencies. CISA encourages every other organization to adopt risk-based vulnerability management and to prioritize KEV-listed flaws, but for private companies, universities, and state and local governments, that is guidance, not a requirement. The directive's compromise-check principle is still useful for anyone. For a bug attacked within hours of disclosure, patching a site does not prove the site was clean before the patch went on.

What this means for you​

Anyone running WordPress, whether on a corporate marketing site, an intranet, a client site, or a personal blog, should confirm the installed version now and treat any unpatched, internet-facing site as possibly compromised. Patching closes the hole. It does not remove a webshell that attackers may have written between September 22 and the moment you updated.

Tech Insider's guidance for checking compromise is to look for unauthorized PHP files, unexpected changes inside or outside your active theme directory, and unfamiliar administrator accounts, and to review server logs for suspicious activity beginning around September 22, 2026, 11:49 UTC. SOCFortress also recommends inspecting temporary directories. Based on the request pattern described above, a reasonable log search is for requests that combine page_id with an unusual pagename value. This is our inference from the published exploit shape, not a signature validated by a vendor. If you find signs of compromise, the recommended response is to isolate the site, preserve logs, rotate credentials, and restore from a known-clean backup.

SOCFortress mentions parameter blocking at the web application firewall (WAF) as an emergency stopgap for sites that cannot update right away. No vendor-validated rule was published in the evidence reviewed here, so treat any blocking rule as temporary until you can install the matching fixed release.

• Update every WordPress site to the fixed release for its branch, such as 7.1.2, 7.0.6, 6.9.9, or 6.8.10, then check the version on each site yourself instead of assuming background updates finished.
• Move any site on WordPress 4.6 or earlier to a supported branch, because those versions will never get a fix for CVE-2026-87902.
• Put sites first if their theme has a top-level page- directory (Twenty Twelve, Twenty Fourteen, and some installations of Neve, Hestia, or Sydney) or if they run on the official PHP Docker image or on cPanel with PHP older than 8.5.
• Check any site that was unpatched after September 22 for new PHP files, theme-directory changes, unfamiliar admin accounts, and unusual page_id and pagename requests in the logs.
• Where you control PHP configuration, check whether register_argc_argv is enabled, since WordPress names it as part of the pearcmd.php route to code execution.
• Federal civilian agencies should handle CVE-2026-87902 under BOD 26-04. Everyone else should treat the KEV listing as CISA's confirmation that attacks are already happening.

The pattern here is patch in the morning, exploitation by afternoon, and a federal KEV listing three days later. For CVE-2026-87902, the KEV entry did not start the emergency. It confirmed an emergency that was already underway. Any WordPress site that has not been patched by now should be handled as a potential incident: update to the fixed release for its branch, check for signs of compromise, and restore from a clean backup if anything suspicious turns up.