WordPress just patched a second critical core vulnerability in the space of a week, and this one is worse in one specific way: it doesn’t need a visitor, a comment, or anyone to click anything. CVE-2026-87902 is a local file inclusion flaw with a CVSS score of 9.2, it requires no authentication and no user interaction, and depending on your server configuration it can escalate straight to remote code execution. Researcher Robert Ressl gets the credit for finding it, and WordPress shipped fixes across every actively maintained branch.
How a page URL turns into a file path attackers control
WordPress builds certain template filenames dynamically, using a pattern like page-{value}.php, where the value comes straight from the URL path being requested. Elsewhere in WordPress core, there are checks meant to stop directory traversal, the classic trick of sneaking ../ sequences into a path to escape the folder you’re supposed to be confined to. On affected versions, this particular filename-construction routine doesn’t go through those checks, so a value in the URL can walk the path outside where it belongs and pull in a different file entirely.
Two conditions decide whether a given site is actually reachable. The active theme needs a top-level folder whose name starts with “page-“, and the file the attacker points at needs a .php extension. If both line up, WordPress happily loads and executes a file nobody meant to expose. That’s local file inclusion by itself, and it can already leak internal file contents or trigger unexpected code paths depending on what gets pulled in.
When LFI becomes full remote code execution
Getting from file inclusion to actual command execution needs one more piece: an existing PHP file already sitting on the server that does something useful when it’s loaded on its own, combined with the PHP setting register_argc_argv being enabled. That setting exposes command-line-style arguments to a script even when it’s being served over the web, which is not something most PHP scripts expect or account for, and it’s exactly the kind of gap that turns “we can read a file we shouldn’t” into “we can make the server run code we chose.”
The setting isn’t obscure by accident, it’s a legacy default. PHP 8.5 and newer ship with it off, but plenty of production servers are still running older PHP versions where it defaults to on, often without anyone having deliberately decided to turn it on or being aware it’s active at all.
What’s patched and what to check first
Every WordPress core version from 4.7.0 through 7.1.1 is affected, which is the entire history of actively used WordPress at this point. Patched releases are out across every branch still receiving security updates: 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, and equivalent point releases going back to 4.7.37. As of publication there’s no public proof-of-concept and no confirmed active exploitation, and it isn’t in CISA’s Known Exploited Vulnerabilities catalog yet. Security vendor Patchstack flagged the two conditions worth checking on your own setup first: does your active theme have any top-level folder starting with “page-“, and is register_argc_argv actually enabled on your PHP configuration. Either one being false meaningfully narrows your real exposure, but neither is something most site owners have ever thought to check.
Our take
What makes this one worth taking seriously isn’t the CVSS number on its own, it’s the authentication requirement, or rather the total lack of one. A comment-based flaw like the one we covered last week still needs an administrator to view the right page at the right moment. This one needs nothing from a human at all, just a request to the right URL on a server where two fairly ordinary conditions happen to be true. That’s a meaningfully larger pool of realistically exploitable sites, even before a public proof-of-concept exists to make exploitation trivial for less skilled attackers.
It’s also the second WordPress core patch in about a week addressing a flaw with a real path to remote code execution, not a plugin issue. Two core-level RCE-adjacent bugs landing back to back is a pattern worth noticing on its own: it doesn’t mean core is suddenly less secure, it means the same class of parsing and file-handling logic keeps getting a harder look right now, and that scrutiny tends to surface more than one finding at a time.
Not the first core flaw we’ve flagged this month
Just last week we broke down Comment2Shell, a WordPress core flaw where a blog comment could escalate into full server control once an administrator viewed the wrong page. That one needed an admin to be in the loop. This one doesn’t need anyone at all, which makes it the more urgent patch of the two despite landing with less public attention so far.
What to do right now
- Update to the patched release for your branch immediately: 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, or the matching point release for older branches. No authentication requirement means there’s no “low-risk window” to wait out.
- Check whether your active theme has a top-level folder starting with “page-“. If it does, treat this patch as non-negotiable regardless of how old or obscure the theme is.
- Check whether
register_argc_argvis enabled in your PHP configuration. If you’re running PHP older than 8.5, assume it might be on until you’ve actually verified it, since that’s the legacy default. - If you’re on an outdated, unsupported WordPress branch with no available patch, that’s now an urgent migration, not something to schedule for later.
- Get a proper penetration test rather than assuming a patched version number means the site is actually safe. Version checks catch known CVEs, they don’t catch what a scoped test against your specific theme and server configuration will.
- For sites built on custom or heavily modified themes specifically, website penetration testing services that dig into theme-level file handling are worth more here than a generic vulnerability scan.
- If the affected site runs custom web application logic on top of WordPress, not just a standard theme and plugin stack, web application penetration testing covers the custom code a version-number check will never catch.