WordPress site owners can close a critical security hole by updating to the release shipped on September 22, 2026. The fix, WordPress 7.1.2, addresses a flaw 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 and allow the attacker to run their own code. WordPress rates the flaw critical with a CVSS score of 9.2 and has assigned it CVE-2026-87902.<\/p>\n
Every WordPress version from 4.7.0 through 7.1.1 is affected. That includes 7.1.1, which shipped in the September 17 security release, so a site updated less than a week earlier still needs this update. This is a separate flaw from the ones that earlier release fixed.<\/p>\n
Reaching the flaw requires no account and no action from a logged-in user. The weakness sits 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, even though neighboring code already used that check.<\/p>\n
The release to install depends on the branch a site runs:<\/p>\n
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.<\/p>\n
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.<\/p>\n
Because the template 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.<\/p>\n
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, 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.<\/p>\n
The flaw was disclosed privately through WordPress’s HackerOne program in July. A detailed write-up published when the fix shipped included a proof-of-concept and a self-contained test lab. The demonstrated attack ran code with the privileges of the web-server account, not full control of the server, and was tested against WordPress 7.0.2 in isolated local labs, not the patched release or any live site. 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.<\/p>\n
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.<\/p>\n
Every WordPress version from 4.7.0 through 7.1.1 is affected. That includes 7.1.1, released on September 17, 2026, so sites updated less than a week earlier still need the new patch.<\/p>\n
No. The flaw allows an unauthenticated attacker to load a PHP file from outside theme folders. Turning that into attacker-chosen code requires the server to already have a PHP file that does something useful when loaded, which is why it only enables code execution on some servers.<\/p>\n
Update to the patched release for the branch you run. WordPress 7.1.2 fixes the 7.1.x branch, with backports down to 4.7.37. WordPress does not offer a separate workaround, so updating is the fix. Sites with automatic background updates enabled will update automatically.<\/p>\n