SURIQ
An unauthenticated flaw in WordPress core has been present in every release since version 4.7.0, and reports now describe attackers using it to plant code on live sites. CISA added CVE-2026-87902 to its Known Exploited Vulnerabilities catalog on September 25, 2026, with a remediation deadline three days later on September 28. The fix is WordPress 7.1.2. The patch is the easy part. The harder problem is that the vulnerable code shipped for close to a decade, which turns this from a patching job into a question of whether you can find every WordPress install you run.
What the flaw does
CVE-2026-87902 is an unauthenticated path traversal in WordPress core page-template resolution that can lead to remote code execution. It carries a CVSS score of 9.2. An attacker who is not logged in can influence how WordPress resolves a page template through the get_page_template() path and pull in a local PHP file from outside the theme directories.
According to Security Affairs, the flaw reaches back to version 4.7.0 and is fixed in 7.1.2, and it was reported by researcher Robert Ressl. Canada's Cyber Centre describes it as a page-template resolution issue and dates active exploitation to September 22, 2026. If you run WordPress and are on any release before 7.1.2, you are in range.
Why "conditional RCE" understates the risk
Both advisories hedge the code-execution claim with a condition: the file inclusion becomes remote code execution only under certain server and theme configurations. That hedge is easy to misread as a safety margin. It is not. Public reports describe attackers abusing pearcmd.php, a helper script that ships with many PEAR-enabled PHP builds, to write a PHP file and then run it. On a lot of shared and cPanel-style hosting, that file is already present.
So the honest way to rank this is as code execution from the first day, not a lesser file read that might escalate later. The "condition" is really about whether a usable local file is reachable, and on common hosting stacks it often is. Treating the bug as read-only until proven otherwise is the kind of assumption that turns a patch window into an incident.
The real problem is finding every WordPress install
A three-day federal patch clock assumes you can list every affected system. For a flaw that spans nearly a decade of releases, that assumption is the weak link. WordPress updates minor versions on its own, but a range from 4.7.0 forward includes plenty of installs with auto-updates disabled, sites handed off years ago, staging copies nobody decommissioned, and subdirectories a client stood up and forgot. Those are the hosts still on a vulnerable core.
File inclusion is not an exotic bug class. Path traversal and file-read flaws are the fifth most common category in our own 90-day triage record, 1,076 of them. What makes CVE-2026-87902 different is the combination: it sits in core rather than a plugin, it needs no login, and its affected range is a decade wide. We have watched the plugin version of this play out before, in an unauthenticated file inclusion in a WooCommerce add-on and in a mass campaign that turned unpatched components into webshells. The core version is the same problem with a far larger blast radius.
How to know if you were hit
Patching closes the hole. It does not tell you whether someone walked through it in the days before you patched, and for a bug exploited since September 22 that window is real. Two observables matter. The first is in your web server access logs: requests carrying traversal sequences or PHP stream wrappers inside template or page parameters. The second is in the webroot itself: a PHP file that appeared or changed around the exploitation window and does not belong to WordPress, a plugin, or a theme.
Access-log requests probing template or page parameters: grep -Ei "template=|page_template=|pagename=" access_log | grep -Ei "pearcmd|php://|%2e%2e" PHP files under the docroot changed since the exploitation window: find /var/www -type f -name "*.php" -newermt "2026-09-20" The PEAR helper appearing as an inclusion target: grep -R "pearcmd" access_log
File-integrity monitoring is the control that pays off here, because it flags a written or changed PHP file whether or not you remembered that host existed. That is the difference between patching and knowing, a point that landed when a WordPress core exploit went public within a day of its patch. When the vulnerable surface is this wide, watching for the exploitation is cheaper than trying to enumerate every host first.
Update to 7.1.2, then sweep your webroots
Update every WordPress install to 7.1.2 today. If your fleet is large or you cannot reach all of it at once, do not wait passively: run the two checks above across your hosts, and prioritize anything on an old core or with auto-updates off. This is the latest in a run of WordPress core flaws we have tracked this quarter, after the wp2shell chain on 6.9 and 7.0 and a stored cross-site scripting bug that pushed the fix to 7.1.1. The lesson repeating across all three is plain: a WordPress estate you cannot inventory is one you cannot patch on a deadline, so the monitoring you stand up now is what protects you the next time core ships a critical flaw.