WordPress has patched a critical vulnerability in its core software that could allow an unauthenticated attacker to make a website load a PHP file from outside its normal theme directories.
On certain server configurations, the flaw could potentially be escalated to arbitrary code execution, allowing an attacker to run their own PHP code on an affected website.
WordPress released the security fixes on September 22 in version 7.1.2 and backported the patch to every WordPress branch that is still supported, reaching as far back as version 4.7.
The project is urging website administrators to update as soon as possible.
The vulnerability is tracked as CVE-2026-87902, has a CVSS score of 9.2, and is rated critical by WordPress.
No user account or interaction from a logged-in administrator is required to exploit the underlying flaw.
Which WordPress Versions Are Affected?
The vulnerability affects WordPress versions 4.7.0 through 7.1.1.
That includes WordPress 7.1.1, which was released during the September 17 security update. As a result, websites that installed the previous security release less than a week earlier may still be vulnerable.
The flaw is separate from the vulnerabilities addressed in that earlier release.
Administrators should update according to their current WordPress branch:
| Current branch | Fixed version |
|---|---|
| 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 |
WordPress has also backported the fix to older supported branches, with the releases extending down to 4.7.37.
The project’s release notes contain the complete list of fixed versions.
WordPress Recommends Updating Immediately
Websites with automatic background updates enabled should receive the security update automatically.
Administrators can also manually update WordPress through:
Dashboard → Updates
Alternatively, the latest release can be downloaded from the official WordPress website.
WordPress has not provided a separate workaround for CVE-2026-87902, making updating the primary mitigation.
How the Vulnerability Works
The vulnerability is related to the way WordPress determines which template file should be used when generating a page.
Part of the template filename is constructed using information derived from the web address.
On vulnerable versions, WordPress did not properly pass that value through an existing security check designed to prevent directory traversal, including ../ path components.
The resulting filename follows a pattern similar to:
page-{value}.php
Under specific conditions, this can cause WordPress to attempt to load a PHP file from outside the directory where it would normally look for the template.
Simply loading a local PHP file does not automatically give an attacker arbitrary code execution. The targeted server must already contain a PHP file that performs a useful operation when loaded.
That additional requirement is why the vulnerability does not automatically provide full code execution on every affected WordPress installation.
Certain Themes Can Increase Exposure
Exploitation also depends on characteristics of the active WordPress theme.
A vulnerable installation needs a top-level theme directory whose name begins with page-, along with a PHP file that satisfies the conditions required by the attack.
Some older themes, including certain legacy default WordPress themes, contain directory structures that can meet these requirements.
Current default WordPress themes do not necessarily have the same structure.
This means the practical impact of the vulnerability can vary depending on the theme and server configuration.
PHP Configuration Can Affect Code Execution
Security company Patchstack identified another important factor in its analysis: the PHP configuration setting register_argc_argv.
Patchstack says administrators can check two conditions when assessing their exposure:
- Whether the active theme contains a top-level directory whose name begins with
page-. - Whether PHP has
register_argc_argvenabled.
Neither condition fixes the WordPress vulnerability, but both can indicate whether a system has the additional characteristics needed for the more serious code-execution scenario.
The register_argc_argv setting is enabled by default on older PHP versions but is disabled by default in PHP 8.5.
Researcher Published Technical Details
WordPress credited Robert Ressl with discovering the vulnerability.
Ressl reported the issue privately through WordPress’s HackerOne bug bounty program in July.
After the security update was released, he published a technical analysis that included a proof of concept and a self-contained testing environment.
In his demonstration, the attack achieved code execution with the privileges of the web-server account.
It did not provide complete control over the underlying server.
Ressl tested the vulnerability against WordPress 7.0.2 in isolated local environments rather than against a live website or the patched version.
Temporary Mitigations for Administrators
Updating WordPress remains the recommended solution.
For organizations that cannot immediately apply the security update, Ressl says administrators can reduce the possibility of the code-execution portion of the attack by:
- Disabling
register_argc_argvfor web requests. - Removing unused PEAR components.
These measures do not fix the underlying WordPress vulnerability and should not be treated as a replacement for upgrading.
Administrators should also avoid removing or modifying WordPress core security checks unless specifically directed by WordPress or another trusted security source.
No Known Exploitation Reported Yet
As of September 22, there were no reports that CVE-2026-87902 had been exploited in real-world attacks.
The vulnerability had also not been listed in the U.S. CISA Known Exploited Vulnerabilities (KEV) catalog at that time.
However, the combination of a critical severity rating, no authentication requirement, and the possibility of code execution under certain configurations makes timely patching important for affected WordPress sites.
What WordPress Administrators Should Do
Administrators should take the following steps:
- Check the current WordPress version.
- Update to the appropriate fixed release for the site’s branch.
- Verify that automatic updates completed successfully if they are enabled.
- Review the active theme for unusual
page-directories. - Check PHP configuration, particularly
register_argc_argv. - Review server and WordPress logs for suspicious requests or unexpected PHP execution.
- Remove unused components and plugins that are no longer required.
The most important step is straightforward: install the WordPress security update as soon as possible.
While exploitation requires additional conditions for the most serious outcome, CVE-2026-87902 demonstrates how a relatively small flaw in template path handling can become a significant security problem when combined with a particular theme and server configuration.
