WordPress 7.1.2 Patches Critical LFI-to-RCE Flaw

A critical vulnerability in WordPress core allowed an unauthenticated attacker to force a site to load a PHP file from outside its theme directories. On certain server configurations, that file loading can escalate to running attacker-controlled code, and the project shipped a fix on September 22 in WordPress 7.1.2 with backports to every supported branch back to 4.7.

WordPress rates the flaw as critical with a CVSS score of 9.2 and assigns it CVE-2026-87902. The project told site owners to update now, and the underlying flaw is separate from the issues patched in the September 17 security release.

What the flaw actually does

At its core, the bug is a local file inclusion in how WordPress chooses the template file for a page. One of the file names the software 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 same check that neighboring code already used. Because the name is constructed as page-{value}.php, an attacker can supply a value that points to a PHP file outside the theme's expected folder.

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.

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.

Who is affected and which update to apply

Every version from 4.7.0 through 7.1.1 is affected. That includes 7.1.1, which was itself released as part of WordPress's September 17 security release, so a site updated less than a week before the September 22 disclosure still needs this new patch to close CVE-2026-87902. The flaw is a separate issue from the ones the September 17 release fixed.

The release a site owner should install depends on the branch they run:

• Sites on 7.1.x should update to 7.1.2
• Sites on 7.0.x should update to 7.0.6
• Sites on 6.9.x should update to 6.9.9
• Sites on 6.8.x should update to 6.8.10
• Sites on 6.7.x should update to 6.7.9
• Sites on 6.6.x should update to 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 of releases is in the release notes.

How the fix reaches sites

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 for the underlying flaw, so updating is the fix.

The project credited Robert Ressl with finding the flaw. He disclosed it privately through WordPress's HackerOne program in July, and 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.

What Patchstack says about exposure

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.

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.

The two conditions are independent: a site can have a page-prefixed folder without register_argc_argv, or the reverse, and only the combination would allow the specific demonstrated path to code execution. Patchstack frames them as indicators rather than guarantees, which means a site without both conditions is still running the vulnerable code and should still patch.

Timeline and private disclosure

Ressl disclosed the flaw privately through WordPress's HackerOne program in July. The patch shipped on September 22, and Ressl published his write-up when the fix became available. The gap between private disclosure and public release is typical for coordinated vulnerability handling, and it allowed the WordPress project to prepare backports for branches going back to 4.7 before details became public.

WordPress and Ressl were contacted for comment.

Ressl's proof-of-concept was tested against WordPress 7.0.2 in isolated local labs. That means the public demonstration did not target the patched 7.1.2 release or any live site, and the code execution he achieved ran with the privileges of the web-server account rather than granting full control of the server.

No known exploitation as of the patch

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. That absence of exploitation is notable because unauthenticated flaws in WordPress core are attractive targets for automated scanning and mass exploitation once details are public.

The vulnerability requires no account and no action from a logged-in user, which lowers the bar for an attacker. But the two additional conditions — a page-prefixed top-level theme folder and a PHP file that does something useful when loaded — mean not every affected site is immediately exploitable for code execution. The flaw still permits local file inclusion on affected versions regardless of those conditions, and WordPress rates the overall issue as critical with a CVSS score of 9.2.

Why this matters beyond one patch

For site owners, the practical consequence is that a site updated less than a week before September 22 may still be carrying an unauthenticated critical flaw. The September 17 release fixed separate issues and left CVE-2026-87902 untouched, so administrators who treat every update as interchangeable could mistakenly assume they are current. The backports down to 4.7.37 are a courtesy for older installations, but running a branch that old carries its own risks, and the availability of a fix does not mean those sites will apply it.

The two-condition nature of the worst case also complicates exposure assessment. A site owner cannot simply check the WordPress version and know whether they are exploitable for code execution; they must also inspect the active theme's folder layout and the PHP configuration for register_argc_argv. Patchstack's indicators are a starting point, but they are not a substitute for patching, and the company says as much.

For the broader WordPress ecosystem, the timing is uncomfortable. A critical unauthenticated flaw disclosed days after a separate security release means administrators who batch updates on a weekly or monthly schedule could have a window where they believe they are patched but are not. The absence of a CISA KEV entry and no reported attacks as of September 22 leave room for a quieter exploitation window, but the public availability of a proof-of-concept and a test lab raises the chance that others will adapt the technique. Sites that cannot update immediately can reduce the route to code execution by turning register_argc_argv off for web requests and removing unused PEAR components, but Ressl notes neither repairs the underlying flaw. Updating remains the fix, and the branches affected span 4.7.0 through 7.1.1.