WordPress 7.1.2 patches critical path traversal vulnerability
WordPress 7.1.2, released September 22, 2026, fixes a critical unauthenticated path traversal vulnerability in WordPress Core, tracked as CVE-2026-87902. The flaw, which carries a CVSS v4.0 score of 9.2 (Critical), can allow an attacker without a WordPress account to force a site to include a readable PHP file from outside the active theme directory. On sites whose theme and server meet certain conditions, that can lead to remote code execution and a full site takeover. The WordPress Security Team also released security backports for every branch back to WordPress 4.7. A Wordfence Intelligence summary table listed the flaw as CVSS 8.1 (High) under one scoring convention, while the main advisory and patch notice use CVSS v4.0 9.2 (Critical).
A path traversal vulnerability is a way to trick software into reading a file outside the folder it is supposed to work in, often by using '..' in a file path. In this case, WordPress Core did not properly check that a template name resolved to a file inside the active theme directory. An attacker who sends a specially crafted request to a vulnerable site can make WordPress include a local PHP file chosen by the attacker. That is known as local file inclusion. If the included file is something like pearcmd.php, a command-line tool included with some PHP installations, and the server has register_argc_argv enabled, the inclusion can become remote code execution, meaning the attacker can run their own commands on the server. The WordPress advisory notes that the official PHP Docker image and default cPanel configurations on PHP before 8.5 can expose exactly this combination.
Exploitation is not automatic on every unpatched site. The WordPress advisory identifies two main conditions. First, the active parent or child theme must contain a top-level directory whose name begins with page-, for example the page-templates folder found in the legacy Twenty Twelve and Twenty Fourteen themes, as well as in the Neve, Hestia, and Sydney themes. Second, the server must have a readable PHP file that produces useful behavior when included, such as pearcmd.php with register_argc_argv enabled. Sites that do not meet both conditions may not be immediately exploitable for remote code execution, but the underlying path traversal remains present in WordPress Core until the update is applied. Theme names alone are not enough to judge exposure because the advisory does not list affected theme-version ranges; administrators should check their installed theme directory structure and server files directly.
The technical cause sits in how WordPress resolves page templates. In vulnerable versions, the get_page_template() function reads the public pagename query variable and applies an extra urldecode() to it before building a template candidate named page-{$pagename}.php. Since WordPress already URL-decodes request parameters once, an attacker can double-encode traversal characters like '..' so that they are only decoded later during template resolution. The resulting candidate is then passed to locate_template(), which joined the candidate to the active theme path and checked whether the file existed, but did not verify that the final path stayed inside an approved theme directory. That combination allowed a crafted page request to escape a compatible page-* directory and point WordPress at a PHP file elsewhere on the server. Wordfence credited Robert Ressl for discovering and responsibly disclosing the flaw, and reproduced the behavior on WordPress 7.1.
The fix adds two layers of protection. get_page_template() now validates the decoded page name with WordPress's validate_file() function before it creates a template candidate, rejecting the traversal syntax used in the attack. In addition, locate_template() now runs existing candidates through a new check called _wp_is_template_path_allowed(). When a path contains traversal components, WordPress resolves its canonical location and confirms that it stays inside an approved theme or theme-compatibility directory before loading it. The first control closes the specific request path, while the second provides defense in depth for other core functions and filters that can supply template names.
Because the September 22 security release covers many older branches, the affected version ranges are branch-specific. A blanket statement like WordPress 7.1.1 and earlier would be wrong, because backports exist for older branches even though their version numbers sort below 7.1.1. The patched versions are: 7.1.2 for the 7.1 series, 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, and 4.7.37. WordPress.org states that only the newest release in the 7.1 series is actively maintained; the older fixes are courtesy security backports. Sites on an older branch should apply the available update immediately and plan an upgrade to a currently maintained release.
Wordfence Premium, Wordfence Care, and Wordfence Response customers received firewall protection against CVE-2026-87902 on September 22, 2026, the same day the vulnerability and updates were released. Wordfence Free users will receive the same rule on October 22, 2026, after the standard 30-day delay. The firewall rule detects traversal syntax in the pagename input, including the encoded form that remains after the firewall's first decoding pass. Firewall protection reduces exposure but is not a replacement for updating WordPress Core.
Site owners should check the WordPress version on every site they manage, update to 7.1.2 or the fixed release for their branch, and then confirm the update actually completed. Automatic background updates do not always succeed. If updating immediately is impossible, confirm that a suitable firewall rule is active and schedule the Core update as soon as possible. Review web server and firewall logs for suspicious requests with traversal-like values in the pagename parameter. If any request reached the vulnerable template path, treat the site as potentially compromised and begin a full incident response: review administrator accounts, recently installed or modified plugins, scheduled tasks, and unexpected PHP files. Primary sources include the WordPress Core security advisory GHSA-7hp8-65ch-5whp, WordPress Core changeset 63792, and the WordPress release archive. For site owners who prefer to have timely WordPress Core updates, hardened server configuration, and automatic backups handled by a provider, managed WordPress hosting such as AEU Hosting (albhosting.eu) is one way to reduce the window between a security release and a patched site, but the responsibility to verify the update still lies with the site owner.