WordPress Core Had an Unauthenticated RCE. Attackers Started Probing Within Hours of the Patch.
WordPress shipped version 7.1.2 on September 22 to fix CVE-2026-87902, a critical, unauthenticated remote code execution bug in core itself, not a plugin, not a theme add-on, the actual WordPress codebase that every site on the platform runs. Patchstack recorded exploitation attempts starting within hours of the patch going public. If you or a client are running WordPress and haven't updated since Monday, this is the post to stop and act on before reading the rest of today's queue.
What the bug actually is
The vulnerability lives in page template resolution. Under specific conditions, an unauthenticated attacker could manipulate that resolution to include a local PHP file of their choosing from outside the active theme's directories. Chained correctly, that becomes remote code execution with no login required at all. WordPress's own security release notes describe it plainly: page template resolution could be made to include "a chosen readable local PHP file outside the active theme directories."
The specific attack chain Patchstack documented requires a theme with a top-level template directory prefixed "page-" and an accessible file like pearcmd.php to complete the exploit. That's a narrower set of conditions than "every WordPress site is instantly compromised," but it's wide enough that this rates a CVSS score of 9.2, and wide enough that attackers went looking within hours rather than weeks.
Credit for responsible disclosure goes to security researcher Robert Ressl. WordPress core's own release, led by John Blackbourn with contributions from the broader community, backported the fix all the way down through the 4.7 branch, which tells you how seriously the core team is treating a bug that can hit sites running years-old WordPress installs, not just the current release.
Why the speed matters more than the CVSS number
I've written about WordPress plugin vulnerabilities more than once on this blog this year, and the pattern is always the same: a patch ships, most site owners don't see the notice for days or weeks, and by the time they do, exploitation is already underway. This one compressed that window to hours. Patchstack's honeypot data showed probing attempts beginning essentially as soon as the patch was public, which means the vulnerability itself, or a close enough approximation from diffing the patch, was trivial enough to weaponize almost immediately.
That's the real lesson here, not the specific CVE. A core WordPress security release moves faster into active exploitation than almost any plugin vulnerability I've covered this year, because core patches get reverse-engineered by attackers immediately given how much of the internet runs on it. If you manage WordPress sites, whether your own or a client's, "I'll get to the update this week" is not a safe posture for a core security release, ever, and this one is a clean example of why.
What to actually check right now
Log into every WordPress install you're responsible for and confirm you're on 7.1.2, or on the corresponding patched point release for your branch if you're intentionally running an older major version (WordPress backported this one unusually far, through 4.7, specifically because of how severe it is). If you manage sites for clients on autopilot with automatic minor updates enabled, this one should already be applied, but verify rather than assume, since some hosts and managed WordPress providers stagger rollout. If auto-updates are off for any reason, whether a custom plugin compatibility concern or a client who insisted on manual control, this is the release that justifies pushing back on that policy, at minimum for security point releases.
What I'd actually do
Patch first, audit second. If you're running any of the theme conditions Patchstack flagged, a "page-" prefixed template directory alongside an accessible pearcmd.php or similar file, treat your site as potentially already probed and check server logs for unusual PHP file writes to temp directories before assuming you dodged it just because you patched today. The honest complication here: most solo operators running a single WordPress blog or a handful of client sites don't have the log-monitoring habits to catch a quiet compromise even after the fact, which is itself worth fixing independent of this specific CVE. A managed host with security monitoring, even a moderately-priced one, is buying you exactly this kind of coverage, and if you're self-hosting WordPress purely to save the monthly fee, weigh that savings against the actual cost of a compromised client site.
Author
Lukas
@lukcombinator