WordPress has shipped an urgent security update after the discovery of CVE-2026-87902, a critical unauthenticated path traversal flaw in WordPress Core that can, under the right conditions, lead to remote code execution. The WordPress Security Team released WordPress 7.1.2 on September 22, 2026, along with security backports for every branch back to 4.7.
What WordPress fixed in CVE-2026-87902
The vulnerability affects WordPress Core’s template resolution logic and carries a CVSS v4.0 score of 9.2, marking it as Critical. In practical terms, an attacker does not need a WordPress account or any user interaction to reach the vulnerable code path.
According to the advisory, the issue could let an attacker make WordPress include a readable PHP file from outside the active theme directory. If the site’s theme layout and server environment line up in a certain way, that local file inclusion can become a route to remote code execution and full site compromise.
Why the bug is serious, even if exploitation is conditional
The security problem is not limited to a plugin or a single theme. It sits in WordPress Core, which means any site running an affected version may be exposed to the underlying path traversal behavior.
That said, WordPress and Wordfence both stress that this is not an automatic one-click takeover on every site. Remote code execution depends on additional conditions, including the presence of a compatible theme directory layout and a readable PHP file elsewhere on the server that has useful behavior when included.
The official advisory points to legacy Twenty Twelve and Twenty Fourteen, as well as Neve, Hestia, and Sydney, as examples of themes with the relevant directory layout. Administrators are advised to check the actual installed theme and filesystem rather than assume exposure from a theme name alone.
How attackers could reach the flaw
The technical issue centers on WordPress template selection. In vulnerable releases, the get_page_template() logic uses the public pagename value, applies an extra URL decoding step, and then builds candidate template names from that value. Because request parameters are already decoded once by the time WordPress processes them, the extra decoding can allow a crafted input to turn into traversal syntax at the wrong moment.
WordPress then passes the resulting candidate to locate_template(). In affected versions, that function could join the candidate to the active theme path and check whether a file existed without confirming that the resolved file stayed within the permitted theme directory. That combination made it possible to escape the theme boundary and point WordPress at another PHP file on the local filesystem.
WordPress 7.1.2 and the security backports
WordPress 7.1.2 contains the fix, and the WordPress Security Team also backported the patch across older maintained branches. The patched versions listed in the advisory are:
- 7.1.2
- 7.0.6
- 6.9.9
- 6.8.10
- 6.7.9
- 6.6.9
- 6.5.12
- 6.4.12
- 6.3.12
- 6.2.13
- 6.1.14
- 6.0.16
- 5.9.18
- 5.8.17
- 5.7.19
- 5.6.21
- 5.5.22
- 5.4.23
- 5.3.25
- 5.2.28
- 5.1.26
- 5.0.29
- 4.9.33
- 4.8.32
- 4.7.37
WordPress.org says only the newest release in the 7.1 series is actively maintained. The older updates are courtesy security backports, so sites on older branches should still plan a broader upgrade path after applying the fix.
How the patch closes the hole
The fix uses two layers of protection. First, get_page_template() now validates the decoded page name before it can be turned into a template candidate. That blocks the traversal pattern at the input stage.
Second, locate_template() now checks candidate paths against a new allowed-template-path test before loading them. If a path contains traversal components, WordPress resolves its canonical filesystem location and confirms that it remains within an approved theme or theme-compatibility directory.
In short, one change closes the known attack path, while the other adds defense in depth for other Core callers and filters that may supply template names.
Wordfence protection and what it means
Wordfence says Premium, Care, and Response customers received a firewall rule on September 22, 2026, the same day the issue was disclosed. Wordfence Free users are scheduled to receive the same protection on October 22, 2026, following the standard 30-day delay.
The rule is designed to catch traversal syntax in the vulnerable pagename input, including encoded forms that may survive the web application firewall’s first decoding pass. Even so, Wordfence notes that firewall protection is a layer of defense, not a replacement for updating WordPress Core.
What site owners should do now
For WordPress administrators, the response is straightforward: check every site, update Core immediately, and confirm the update completed successfully. Automatic background updates should not be assumed to have worked everywhere.
- Verify the WordPress Core version on each site you manage.
- Update to WordPress 7.1.2 or the fixed release for your branch.
- Confirm the update actually completed.
- If you cannot patch immediately, ensure an appropriate firewall rule is active and schedule the update as soon as possible.
- Review server and firewall logs for suspicious requests involving traversal-like values in the pagename parameter.
- If evidence suggests the vulnerable template path was reached, treat the site as potentially compromised and begin incident response.
That last point matters because successful exploitation can go beyond a blocked request. If an attacker managed to reach a usable local file and execute code through the template path, the result could include altered admin accounts, unexpected PHP files, or changes to scheduled tasks and plugins.
A reminder that “conditional” is not the same as “safe”
The need for a specific theme layout and server-side file does reduce the number of installations that can be turned directly into code execution. It does not make the bug low risk. The vulnerable behavior remains reachable over the internet, requires no credentials, and exists in WordPress Core until patched.
For that reason, the safest assumption is that any unpatched site is at risk. The correct remediation is to move to the fixed release for your branch and verify that the patch is in place.
Source: Original report
Was this helpful?
Explore more: WordPress Troubleshooting More WordPress & CMS Tech News
Last Modified: September 23, 2026 at 10:32 pm
0 views
