CISA adds actively exploited WordPress core file-inclusion flaw CVE-2026-87902 to KEV

What happened

WordPress shipped a fix on 22 September for a core vulnerability that lets an unauthenticated attacker influence which PHP file the page-template resolution logic loads. Tracked as CVE-2026-87902, the flaw lets an attacker make get_page_template() include a readable local .php file from outside the active theme directories. Where both the server and the active theme meet certain conditions, that inclusion can be turned into remote code execution [3][4].

The patch went out in WordPress 7.1.2, with backports covering every branch the project still supports, as far back as 4.7 [3]. A GitHub security advisory for the WordPress development repository carries the same date; it was circulated on Hacker News on 22 September [6].

Within hours of disclosure, attackers were reported to be exploiting it [4][5]. On 25 September, CISA added CVE-2026-87902 to the Known Exploited Vulnerabilities catalogue, describing it as a remote file inclusion issue and setting a due date of 28 September. Known ransomware use is listed as unknown [1].

Who is affected

Any self-hosted WordPress installation running a version earlier than the relevant patched release. Because the project backported fixes to branches going back to 4.7, sites on older long-lived branches are in scope as well and should not assume they were unaffected [3].

The file-inclusion step does not require an account, so the reachable attack surface is simply “the site is on the internet” [1][4]. Whether that step becomes code execution depends on preconditions in the server configuration and the active theme [1]. None of the available sources enumerate those preconditions in detail, so you cannot safely conclude from public reporting that a given site is unexploitable — treat every unpatched install as at risk.

Managed WordPress hosts may have patched or deployed edge rules on your behalf. Confirm that directly rather than assuming it.

How it works

The mechanism, as far as the sources describe it, is a path traversal in template resolution [5]. WordPress decides which theme file renders a given page; an unauthenticated attacker can steer that decision to a .php file outside the theme directories. PHP include executes whatever it loads, so under the right conditions the result is code running on the server [1][4][6].

The sources do not describe post-exploitation activity for this specific flaw, so what attackers are doing after gaining execution is not established by public reporting. As a general matter, code execution in a WordPress context puts site files and data within reach.

One detail worth separating out: earlier in the same week, researchers published a proof of concept for a distinct WordPress core issue dubbed “Click2Shell”, a CSRF chain fixed in version 7.1.1 that force-installs a theme from the official catalogue and executes PHP during a Customizer preview. That one requires a logged-in administrator to click a crafted link. In that chain, BleepingComputer notes the resulting execution can reach wp-config.php, which holds database credentials and authentication secrets, and enable rogue administrator accounts or injected scripts [2]. The sources do not state any relationship between Click2Shell and CVE-2026-87902, and they were fixed in different releases. Do not treat the 7.1.1 update as coverage for CVE-2026-87902.

A note on the score

Our computed severity for this item is high. The CVSS figure we hold for CVE-2026-87902 is 8.1 with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The Hacker News reports 9.2 [4]. The sources conflict on the number; the practical picture — unauthenticated, network-reachable, exploited in the wild, patch available — does not change either way.

What to do

• Update to WordPress 7.1.2, or the patched release for your branch, now. CISA set a due date of 28 September in the KEV entry, which is an indication of how the agency read the urgency [1][3].
• Inventory before you assume. Enumerate every WordPress install you own, including staging sites, abandoned microsites and subdirectory installs. These are the ones that stay unpatched.
• Treat internet-facing installs that stayed unpatched after 22 September as candidates for investigation. Exploitation was reported within hours of disclosure [4][5], but no source we have describes exploitation scale, targeting or indicators of compromise, so scope your triage on your own exposure. Check for unexpected administrator accounts, modified or newly created .php files under wp-content, and scheduled tasks you did not create.
• Rotate secrets if you find evidence of execution. Database credentials and the authentication secrets stored in wp-config.php should be treated as exposed.
• Review web server and PHP logs for requests that manipulate template or page parameters with traversal sequences, and for POSTs to unfamiliar files.
• Set DISALLOW_FILE_MODS where your workflow permits. Patchstack notes it blocks forced theme and plugin installation, which mitigates the separate Click2Shell chain rather than this flaw [2].
• Confirm with your host whether they applied the core update or a virtual patch, and on which date.
• Then fix the process. Enable automatic core updates for minor and security releases unless you have a specific reason not to, and make sure someone owns the sites nobody remembers owning.