A WordPress core RCE is under active attack. Get every client site onto 7.1.2

This one is core, not a plugin. CVE-2026-87902 is an unauthenticated path traversal in WordPress’s page-template resolution, rated CVSS 9.2, fixed in WordPress 7.1.2 on September 22 — and according to Patchstack’s own attack telemetry, the first exploit attempts arrived at 11:49 UTC the same day, built from the patch diff rather than from independent discovery. This is the scenario that patching a whole client portfolio the day a fix lands exists for.

The facts

• Unauthenticated path traversal in get_page_template() (CWE-98) leading to local file inclusion and, under the right conditions, remote code execution — no login, no user interaction
• Affects every WordPress release from 4.7.0 through 7.1.1. Fixed in 7.1.2, 7.0.6, 6.9.9, 6.8.10 and backported down every supported branch to 4.7.37, per the official 7.1.2 release post
• Responsibly disclosed by Robert Ressl
• CISA added it to the Known Exploited Vulnerabilities catalogue on September 25, with a federal remediation deadline of September 28 — today
• Patchstack reports traffic against this CVE running at more than ten times its first-evening volume, and public Nuclei templates are now circulating, so it is no longer only skilled operators

Two preconditions, and the first one is easy to check

Exploitation is conditional, which is why “critical” doesn’t mean “every site”:

1. The active parent or child theme has a top-level directory whose name starts with “page-“. The advisory names Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney. If you have inherited sites on any of those, start there
2. A readable PHP file the attacker can reach. The observed chain uses pearcmd.php with register_argc_argv enabled — which is the default in official PHP Docker images and on cPanel hosting running PHP below 8.5

Stage three of what Patchstack observed is attackers using config-create to write a file of their choosing, with content they control, to disk. That is a shell, not a proof of concept.

What agencies should do today

• Confirm every client site actually reports 7.1.2 (or the patched version on its branch). Auto-updates handle most of it; the sites that bite you are the ones where someone disabled them years ago for stability
• Check your portfolio for Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney first, plus any custom theme with a top-level page- folder
• If a site genuinely cannot be updated today, disabling register_argc_argv breaks the pearcmd chain and drops the impact from code execution to information disclosure. That is a stopgap, not a fix
• Grep access logs for the tells: a pagename parameter containing %2e%2e or %252e%252e, requests pairing pagename with page_id, references to pearcmd, +config-show or +config-create, and the user agents cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0
• On any site that looks probed, check /tmp and /var/tmp for unexpected .php files before you call it clean

Six days between the patch and today is a long window when exploitation started on day zero. If a site was vulnerable and internet-facing, updating closes the hole but does not undo anything that already happened — that part needs a look at the logs.

What this means for Codelibry clients

If you’re on one of our maintenance plans, 7.1.2 is already applied across your sites and it will appear as its own line in your next monthly maintenance report, along with the theme check and the log review for this specific CVE. There is nothing for you to action. If you’re not on a plan, this is a fair illustration of the gap one closes: the patch shipped on a Tuesday, attackers were probing for it by lunchtime, and the difference between a patched site and a compromised one came down to who was watching that week.

Source: Patchstack