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, while the current default themes do not.
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.
WordPress credited Robert Ressl with finding the flaw, which he disclosed privately through its HackerOne program in July. Ressl published a detailed write-up when the fix shipped, along with a proof-of-concept and a self-contained test lab. His demonstrated attack ran code with the privileges of the web-server account, not full control of the server, and he tested it against WordPress 7.0.2 in isolated local labs, not the patched release or any live site.
Ressl says operators who cannot update immediately can reduce the route to code execution by turning register_argc_argv off for web requests and removing unused PEAR components, though neither repairs the underlying flaw.
As of September 22, there were no reports of the flaw being used in attacks, and it had no entry in the U.S. CISA Known Exploited Vulnerabilities catalog.
WordPress and Ressl were contacted for comment.
