WordPress 7.1.2 Fixes Unauthenticated File Inclusion

WordPress 7.1.2 arrived on 22 September 2026 as a security-only release with a single fix. Security vendor Patchstack calls it the most serious WordPress patch in a while. The flaw is an unauthenticated local file inclusion (LFI) in how WordPress resolves page templates. LFI is a type of vulnerability that lets an attacker make a web application open a local file that should not be accessible. This one can reach remote code execution (RCE), meaning a remote attacker could ultimately run their own code on the affected web server. Patchstack says its customers are protected by a RapidMitigate rule, but it still recommends updating to the most recent WordPress version available.

The vulnerability was reported by Robert Ressl and affects WordPress Core from version 4.7.0 through version 7.1.1. It carries a CVSS 4.0 score of 9.2, a very high severity rating on the Common Vulnerability Scoring System, and is classified as CWE-98, a category for improper control of the filename used in an include statement. The full CVSS vector is AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. CVE-2026-87902 has been assigned. Because every supported branch back to 4.7 is affected, close to ten years of releases are vulnerable, and no user account is needed to launch the attack.

The technical cause sits in the get_page_template() function in wp-includes/template.php. When WordPress renders a page, it builds a list of candidate template filenames from the pagename query variable, which comes straight from the browser request. A query variable is a piece of information sent in the web address that WordPress uses to decide what to display. Next to the vulnerable code, another candidate was already passed through validate_file(), WordPress's own check for path traversal, a technique that tries to use .. in a filename to escape an intended folder. The pagename branch did not have that check. Specifically, WordPress built a filename in the form page-{pagename}.php, so an attacker's payload has to continue from a directory that starts with "page-" and must end with .php because the extension is appended. The practical precondition is an active theme with a top-level directory named like page-templates, which legacy default themes and many popular third-party themes have. An extra urldecode call is what turns a traversal-shaped slug into a real filesystem path. Patchstack did not publish a working exploit request.

Local file inclusion by itself does not guarantee code execution. Including a local .php file runs whatever that file does, but to gain control an attacker needs a readable .php file on the server that behaves usefully when included. The well-known candidate is PEAR's pearcmd.php, and that only becomes useful when PHP is running with register_argc_argv enabled, a setting that puts command-line arguments into PHP variables. That setting is on by default in official PHP Docker images, which are pre-built server environments, and in cPanel environments, a popular hosting control panel, on PHP versions below 8.5. This makes the condition common rather than unusual. The honest framing is a conditional chain: unauthenticated file inclusion is always possible under the right theme condition, and code execution follows when the server configuration lines up. Site owners should treat it as critical unless they have verified their own stack does not meet those conditions.

WordPress shipped two changes in 7.1.2. First, it applies the same validate_file() check to the decoded pagename before building the template filename. Second, and more importantly, it introduces a containment check in a new function _wp_is_template_path_allowed(). Every resolved template must now pass a test: a file path that exists and does not contain .. is allowed, otherwise the real path is resolved and must sit inside the stylesheet directory, the template directory, or theme-compat. This second change goes beyond the reported bug and suggests the WordPress security team treated template path resolution as a class of problem rather than a single instance.

The release timeline was compressed. On 22 September 2026 WordPress published 7.1.2 with backported fixes for every supported branch down to 4.7. The same day, advisory GHSA-7hp8-65ch-5whp was published and CVE-2026-87902 assigned. Patchstack added the issue to its vulnerability database and deployed a RapidMitigate rule to protected sites. Site owners should update from Dashboard > Updates or download from WordPress.org. Automatic background updates should already have applied it. Because fixes were backported, older sites can take the fix without a major version jump. Only the most recent WordPress version remains actively supported, and that is the version to be on.

If you cannot update immediately, two checks reduce uncertainty: confirm whether your active theme has a top-level directory whose name begins with "page-", and confirm whether your PHP has register_argc_argv enabled. Neither check is a fix, but they tell you how close to the worst case you are. For readers who use a managed WordPress host such as AEU Hosting, confirming with the provider that this security update has been applied is a sensible step, because managed platforms generally handle core updates behind the scenes.