WordPress released security updates on September 22 for a critical unauthenticated path traversal flaw that lets an attacker with no account make a site's page template resolution include a chosen readable local PHP file outside the active theme directories. On some server configurations, that can escalate to remote code execution.
Tracked as CVE-2026-87902 and rated 9.2 on the Common Vulnerability Scoring System, the flaw affects every WordPress version from 4.7.0 through 7.1.1. That includes 7.1.1, the security release that shipped on September 17, which addressed separate issues — so a site updated less than a week ago still needs this patch. WordPress credited Robert Ressl with finding and reporting the flaw. He disclosed the flaw privately through the WordPress HackerOne program in July and published a write-up, a proof-of-concept, and a self-contained test lab when the fix shipped.
Vulnerability at a glance
| Item | Detail |
|---|---|
| Identifier | CVE-2026-87902 / GHSA-7hp8-65ch-5whp |
| Severity | 9.2, critical |
| Affected | 4.7.0 – 7.1.1 |
| Fixed in | 7.1.2 + branch backports |
| Access needed | No account, no user action |
| Extra conditions | page-* theme folder, register_argc_argv |
| Exploitation | None reported as of Sept 22 |
What happened
The vulnerability sits in how WordPress chooses the template file for a page. One of the filename components is built from part of the web address, and affected versions did not run that value through the same ../ traversal check that neighboring code already used. The resulting filename follows the pattern page-{value}.php. A working attack also requires the active theme to have a top-level folder whose name starts with page- and a target file that ends in .php. Some themes, including older default WordPress themes, ship a folder that fits this pattern.
Loading a local PHP file runs whatever instructions that file already contains. Turning that into attacker-controlled code execution requires a second condition: the server must already have a PHP file that performs an action the attacker can abuse. That is the "some servers" qualifier in WordPress's description, and it limits the worst-case outcome to a subset of installations.
Fixed releases by branch
WordPress backported the fix to every branch it still supports. The update to install depends on the branch you run:
| Branch | Update to |
|---|---|
| 7.1.x | 7.1.2 |
| 7.0.x | 7.0.6 |
| 6.9.x | 6.9.9 |
| 6.8.x | 6.8.10 |
| 6.7.x | 6.7.9 |
| 6.6.x | 6.6.9 |
The WordPress release archive records 7.1.2, 7.0.6, 6.9.9, 6.8.10 and 6.7.9 as September 22 releases. WordPress's own release note says the remaining backports are in progress and "will ship as they become ready", while The Hacker News reports the sweep reaching 4.7.37. Administrators on long-term branches should check the current package on the release archive rather than assume an older patch is already out.
Sites with automatic background updates enabled will begin the update automatically; other administrators can apply it from the dashboard under Updates or download the release from WordPress.org. WordPress does not offer a separate workaround, so updating is the fix.
Exposure indicators
Security vendor Patchstack identified two checks that help site owners gauge how close they are to the worst case:
- Whether the active theme has a top-level folder whose name begins with
page-. - Whether PHP is running with
register_argc_argvturned on, a setting that a known code-execution technique depends on. It is off by default on PHP 8.5 and on by default on older PHP versions.
Neither indicator is a fix, Patchstack says, but both show how exposed a site is while the core update is scheduled.
What administrators should do
- Update to the fixed release for the installed branch, or let automatic background updates run. WordPress is recommending an immediate update.
- Confirm the running WordPress version after the update.
- Review the active theme for top-level folders whose names begin with
page-. - Review web server and WordPress logs for unusual requests that predate the patch.
- Review PHP settings and remove unused themes and files that can execute PHP.
Everything beyond the update is an exposure check rather than a fix: neither a theme folder nor the register_argc_argv setting substitutes for the core patch. LavX News notes that the update does not require changes to the site's theme or hosting configuration either.
Threat status
As of September 22, there were no reports of the flaw being used in attacks and no entry for CVE-2026-87902 in the U.S. CISA Known Exploited Vulnerabilities catalog.
Why it matters
Two things make this more than a routine patch. The flaw needs no account and no action from a logged-in user, so exposure does not depend on how a site is used — only on what it runs. And it spans every branch back to 4.7.0 while the September 17 release covered separate issues, which means a site can look freshly updated and still be vulnerable.
The worst case also concentrates on older installations. The chain needs a theme folder named page-*, and register_argc_argv — the setting a known local-file-include code-execution technique depends on — is enabled by default on PHP versions older than 8.5. Legacy PHP plus an older bundled theme is where a local file include is most likely to become code execution.
Our take
The flaw is severe on paper: unauthenticated, CVSS 9.2, and backported to every supported branch. But the chain requires a theme folder named page-* and a permissive PHP setting that modern PHP versions disable by default, which narrows the immediate blast radius — the published proof-of-concept runs with web-server account privileges, not full control of the server. The real risk is the long tail of older sites on legacy PHP, where administrators may sit exposed until they apply the update.
