WordPress has fixed a critical flaw in its core software that lets an attacker with no account make a site load a PHP file from outside its theme folders.
On some servers, that can go further, allowing the attacker to run their own code. The fix shipped on September 22 in WordPress 7.1.2, with fixes for every branch the project still supports, back to 4.7, and WordPress is telling site owners to update now.
WordPress rates the flaw as critical, assigns it a CVSS score of 9.2, and assigns it CVE-2026-87902. Reaching it requires no account and no action from a logged-in user.
Every version from 4.7.0 through 7.1.1 is affected. That includes 7.1.1, from WordPress’s September 17 security release, so a site updated less than a week ago still needs this one. It is a separate flaw from the ones that the release fixed.
The release to update to depends on the branch you run:
| Branch you run | 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 |
WordPress backported the fix to every older branch it still supports as a courtesy, down to 4.7.37. The full list is in the release notes.
Sites with automatic background updates enabled will start the update automatically. Others can update from the dashboard under Updates, or download the release from WordPress.org. WordPress does not offer a separate workaround, so updating is the fix.
Loading a local PHP file runs whatever that file already does. Turning that into code of the attacker’s choosing requires a second condition: the server must already have a PHP file that does something useful when loaded. That is the “some servers” in WordPress’s description, and it is why the flaw does not mean full code execution on every affected site.
The flaw is in how WordPress chooses the template file for a page. One of the file names it builds comes from part of the web address, and on affected versions WordPress did not run that value through its own check for ../ traversal steps, the check the neighboring code already used.
Because the name is built as page-{value}.php, a working attack also needs the active theme to have a top-level folder whose name starts with page-, and the target file has to end in .php. Some themes, including older default WordPress themes, ship a folder that fits.
Security vendor Patchstack, in its own analysis, says two checks tell a site owner how exposed they are: whether the active theme has a top-level folder whose name begins with page-, and whether PHP is running with a setting called register_argc_argv turned on, which a known code-execution technique depends on.
Neither is a fix, the company says, but both show how close a site is to the worst case. That setting is off by default on PHP 8.5 and on by default on older PHP versions.
As of September 22, there were no reports of the flaw being used in attacks, no public proof-of-concept exploit, and no entry for it in the U.S. CISA Known Exploited Vulnerabilities catalog.
WordPress credited Robert Ressl with finding and reporting the flaw. The Hacker News has contacted WordPress and Ressl for comment.
