WordPress on KEV: what to do about CVE-2026-87902

CVE-2026-87902 is a WordPress Core issue (remote/local file inclusion via page-template resolution). Without logging in, an attacker can — under certain conditions — make Core include a chosen readable `.php` file outside the active theme directories.

If server and theme preconditions line up, that can lead to remote code execution. Not every vulnerable version is automatically “already breached” — but unauthenticated reach plus a KEV listing mean: patch now, not next sprint.

The fix shipped on 22 September 2026 in WordPress 7.1.2 (and backports down to 4.7). On 25 September CISA added the CVE to Known Exploited Vulnerabilities — a three-day federal clock; for private teams that is a priority signal, not permission to wait.

Why KEV beats a pretty CVSS: KEV and EPSS in plain language. How to read finding statuses: does a CVE affect you.

Any WordPress Core site below the safe build for its branch: storefronts, landings, WooCommerce shops, agency multisites, “temporary” copies on subdomains.

Plugins and themes do not close this CVE by themselves — you need a Core update (or branch backport). Updating Ninja Forms / WooCommerce is a separate story.

Related: old PHP on the same host → also check PHP2Shell. Forgotten stands: new subdomains.

Officially: move to 7.1.2 or newer on the 7.1 branch. Older branches need the matching security backport (e.g. 7.0.6, 6.9.9, down to 4.7.37 per WordPress advisories).

• 7.1 branch → at least 7.1.2
• 7.0 branch → at least 7.0.6
• Older branches → backport from the WordPress security list (through 4.7.37)
• Only the latest branch is actively supported — sitting forever on 5.x/6.x without a backport is riskier than usual

Automatic updates often pick up security releases — still verify the version: some hosts disable auto-updates or fail on limits.

1. In wp-admin: Dashboard → Updates → update WordPress to a safe build. Take a backup first if the host does not.

2. If there is no button — hosting panel or ticket: “need WordPress ≥ 7.1.2 (or branch backport) for CVE-2026-87902 / KEV”.

3. On managed plans ask: which Core version am I on, and did the patch land?

4. After updating, open the site in a private window and confirm the version in the dashboard.

Update Core on every instance (wp-cli `core update` / image with patched WordPress). Do not trust “the main site only”.

Multisite and white-label clients: walk the domain list. Staging and `dev.` are often forgotten — patch or take them off the internet.

After the patch: review logs for odd `pagename` / `page_id` around disclosure dates; check unexpected admins and mu-plugins.

Do not run public PoCs on production. For an outside version check: Radar.

The question is not “does the CVE exist” but “do we expose WordPress, and is a vulnerable version visible”.

• Add the root domain in signalfort and verify DNS
• Wait for host discovery and stack matching
• If WordPress/version are visible and matched, you get a finding (first as a match)
• “Confirmed” only after a safe check on a paid plan — not the same as “we were breached”

Start: free check. Also: check a site from outside.

• Do not assume “plugins updated means Core is fine”
• Do not leave old stands on the same vulnerable branch
• Do not run public exploits against production
• Do not confuse KEV (“already used in attacks”) with a confirmed incident on your site

Confirm a safe build in wp-admin and from outside if the version is visible.

Review administrator users, must-use plugins, unusual files under `wp-content`.

If you suspect compromise — isolate the host and follow IR. signalfort helps with exposure and matches; it does not replace on-server forensics.