WordPress 7.1.2 security update fixes unauthenticated path traversal

WordPress 7.1.2 fixes an unauthenticated path traversal issue in page-template resolution that WordPress says can lead to conditional remote code execution. The update is small, but the public Core patch shows why it matters.

What WordPress 7.1.2 fixes

WordPress 7.1.2 was released on September 22, 2026 as a focused security update. The issue is in WordPress Core rather than a specific plugin or theme, and it affects the logic used to choose the PHP template for a requested page.

WordPress describes the vulnerability as an unauthenticated path traversal issue in page-template resolution leading to conditional remote code execution. The word conditional matters: the public disclosure does not say that every unpatched site can be taken over with a single request.

What the public patch tells us

The security-relevant change is in wp-includes/template.php, inside get_page_template(). WordPress URL-decodes the requested page name because encoded and multibyte page names can legitimately be part of the template hierarchy.

In WordPress 7.1.1, the decoded page name was added as a possible template filename whenever it differed from the original value. The important condition was effectively $pagename_decoded !== $pagename.

WordPress 7.1.2 adds a second requirement before that decoded value is considered: 0 === validate_file( $pagename_decoded ).

That is the key fix. WordPress now validates the decoded page name before it can become part of a PHP template path. An encoded request can therefore no longer decode into path information that fails WordPress's file-path validation and still enter this branch of template resolution.

Does this mean every WordPress site was directly exploitable?

No. The vulnerable code path is in Core, so this is much broader than a bug limited to one plugin or theme. But path traversal does not automatically equal remote code execution.

For the traversal to become code execution, additional conditions have to make a useful PHP file reachable through the resulting template lookup. WordPress has not publicly documented every required condition, so claims that every affected site can be remotely compromised in exactly the same way would go beyond the available evidence.

The practical conclusion is simpler: this is an unauthenticated Core vulnerability with potential code-execution impact, so there is little reason to leave an affected production site unpatched.

Which sites should update?

Sites running WordPress 7.1.1 should update to 7.1.2. WordPress has also published corresponding security releases for older affected branches. Current backports include WordPress 7.0.6, 6.9.9, 6.8.10, and 6.7.9; consult the official 7.1.2 release notes for the appropriate version if a site is on an older branch.

Because the bug is in Core, a simple brochure site is not automatically exempt just because it has few plugins. WooCommerce, membership, editorial, and heavily customized sites deserve the same prompt patching, followed by checks of the workflows that matter to the business.

What site owners should do now

1. Confirm the current WordPress version. Do not assume automatic background updates completed successfully.
2. Take or confirm a current backup. For transactional sites, include both files and database.
3. Install the appropriate patched Core release.
4. Verify the frontend and wp-admin. Check editing, forms, logins, and other important functionality.
5. For WooCommerce, test the transaction path. Verify cart, checkout, payment, order creation, emails, subscriptions, and critical integrations where applicable.

Our WordPress 7.1.1 security article covered the much broader set of fixes released only days earlier. If a site was updated to 7.1.1 after that release, it should now be checked again for 7.1.2.

Do you need to investigate for compromise?

Merely discovering that a site ran an affected version is not evidence that it was exploited. For a site with no suspicious behavior, the immediate priority is to patch, confirm the version, and verify normal operation.

A deeper review is justified when there are actual warning signs such as unfamiliar administrator accounts, modified PHP files, unexplained redirects, injected spam pages, hosting malware alerts, or other unexpected changes. Our guide on how to tell if WordPress has been hacked provides a practical first-pass checklist.

Updating closes the known vulnerable Core path. It does not clean an already compromised installation or remove persistence that may have been added before the patch.

The practical takeaway

WordPress 7.1.2 is a small but important security release. The public patch adds file-path validation to the URL-decoded page name before WordPress considers it as part of page-template resolution.

The issue is unauthenticated and sits in Core, while successful remote code execution is described as conditional. That is enough to justify prompt updating without overstating that every affected WordPress site was trivially exploitable or already compromised.

FAQ