CISA confirms attacks on WordPress core file inclusion flaw

Attackers are exploiting a flaw in the core of WordPress itself, not in a plugin or theme, according to the US Cybersecurity and Infrastructure Security Agency. CISA added CVE-2026-87902 to its Known Exploited Vulnerabilities (KEV) catalog on 25 September and gave federal civilian agencies until 28 September to deal with it. Because the bug sits in core code rather than an optional add-on, every self-hosted WordPress site carries it until it runs 7.1.2 or a patched security release on an older branch; the fix was backported to every branch back to 4.7.

What the flaw does

CVE-2026-87902 is a file inclusion weakness (CWE-98) in the code WordPress uses to work out which page template to render. An attacker with no account on the site can steer that lookup toward a PHP file of their choosing, as long as the file already exists on the server and the web process can read it, including files that live outside the active theme’s own folders. The CVE record describes code execution as the possible end result, but only when certain conditions on both the server and the active theme are satisfied. It does not spell out publicly what those conditions are.

That caveat is reflected in the scoring. The CISA-supplied CVSS 3.1 base score is 8.1 (High), with network access, no privileges and no user interaction required, but high attack complexity. CISA’s own SSVC assessment rates the technical impact as total and the flaw as not automatable. In other words, a successful attack hands over the server, but it is not a one-request, spray-the-internet bug on every install.

What is confirmed, and what is not

The confirmed facts are narrow but significant:

• Exploitation is real. CISA lists the vulnerability as exploited in the wild, and its SSVC entry in the CVE record moved from no known exploitation when the CVE was published on 22 September to active exploitation on 25 September.
• The affected range is broad. The CVE record marks every WordPress version before 7.1.2 as affected, with 7.1.2 the first fixed release and the fix backported to older branches as far back as 4.7.
• Forensic triage is required, not just patching. The KEV entry is flagged for forensic triage under Binding Operational Directive 26-04, meaning federal agencies must check whether a system was already compromised before the fix went on, not simply apply it.

Plenty remains unknown. CISA has not said who is exploiting the flaw, how widely, or against which kinds of organisation. Whether ransomware operators are using it is recorded as unknown. No indicators of compromise have been published alongside the catalog entry, and the server and theme preconditions needed for code execution are not public. Treat any claim of mass exploitation you see elsewhere with caution until a government source says so.

Why the three-day deadline matters

Under BOD 26-04, CISA derives KEV due dates from evidence of public exposure, technical impact and whether exploitation is automatable, and its guidance cites three days as the deadline for the highest-risk combination. CISA has not explained how it arrived at the date for this particular entry. The exposure side is plain enough: WordPress sites are internet-facing by design, and a compromise gives an attacker a foothold on a server that often also holds database credentials, API keys for mailing and payment services, and session secrets.

The directive’s forensic triage guidance is written for federal agencies, but its sequence works for anyone running a WordPress estate. It asks responders to scope affected systems within the first hours, capture volatile evidence such as memory before changing anything where that is possible, then patch and contain, analyse, and reach an escalation decision within about 72 hours. CISA presents those timings as recommended targets rather than requirements.

What to do now

1. Find every WordPress install. Include marketing microsites, staging copies, agency-hosted client sites and abandoned installs that still answer on a public address. Version checks from the dashboard, the command line or a vulnerability scanner will show which ones are not yet on 7.1.2 or the latest security release of their branch.
2. Preserve evidence before you update, where you can. On sites that matter, take a snapshot or disk image and save web server and PHP logs first. Updating can overwrite the traces that show whether the flaw was used.
3. Update to 7.1.2, or to the latest security release of your branch if you run an older one. Where automatic core updates are enabled, confirm the update actually landed rather than assuming it did; sites with automatic updates disabled, or with file permissions that block updates, may not have received it.
4. Look for signs of earlier compromise. Review access logs from 22 September onward for unusual requests against template-rendering paths from unauthenticated clients, check for unexpected PHP files in upload and cache directories, and look for new administrator accounts or recently modified core, theme and plugin files.
5. Rotate secrets on any site you cannot clear. If triage is inconclusive, change database passwords, the authentication keys and salts in the site configuration, and any third-party API keys stored on the server.
6. Reduce what the web process can read. Tightening file permissions and removing stray PHP files, old backups and unused themes shrinks the set of files an inclusion bug could reach.

Organisations outside the federal government are not bound by the 28 September date. The practical point still holds: this is an exploited bug in WordPress core rather than an optional plugin, and the combination of confirmed attacks and a required compromise check puts it ahead of routine patching. The CVE search covers related exploited web-application flaws.

Source: Cybersecurity and Infrastructure Security Agency (CISA)