Skip to content
TrustList
News

WordPress patches a critical pre-auth path traversal that can reach code execution

Editorial

By TrustList Editorial

WordPress 7.1.2 fixes CVE-2026-87902, an unauthenticated path traversal in page-template resolution that can load an arbitrary local PHP file. Every version from 4.7.0 to 7.1.1 is affected, and probing began within five hours of the release.

About WordPress patches a critical pre-auth path traversal that can reach code execution

WordPress patches a critical pre-auth path traversal that can reach code execution

22 September 2026 — WordPress shipped 7.1.2 on 22 September 2026 with a fix for CVE-2026-87902, a flaw the project rates critical at CVSS 9.2. It needs no account, no logged-in victim and no plugin: an unauthenticated request can make the core page-template resolution in get_page_template() include a chosen readable local PHP file from outside the active theme directories. Where the server environment and the active theme line up in a particular way, that becomes remote code execution — which is why the advisory describes the outcome as conditional rather than certain.

What is affected, and what is not

Every release from 4.7.0 through 7.1.1 is vulnerable, and the project backported the fix to every branch it still supports, back to 4.7. That is an unusually long tail, and it is the practical problem: the sites most likely to be running a 2016-era branch are also the ones least likely to have an owner watching a security feed.

The precondition language matters for triage, not for scheduling. Whether a given site reaches code execution depends on the theme and the server, and working that out per site takes longer than applying the update. Treat the update as the response and the analysis as optional.

The clock that has already started

Patchstack recorded the first probing attempts at 17:44 UTC on 22 September — under five hours after 7.1.2 was published — and a working proof of concept was circulating publicly the same day. A patch release is itself an exploitation aid when the diff is public, and this one was reverse-engineered quickly.

What to do about it

Update to 7.1.2, or to the patched release on whichever branch you are pinned to. If your hosting provider applies core security updates automatically, confirm it has actually happened rather than assuming it; automatic core updates are frequently disabled on managed or bespoke installations, and a staging site that nobody has logged into for a year is still reachable from the internet.

After updating, check access logs for requests to page-template parameters carrying traversal sequences, and for any PHP file written under the uploads directory — the usual second step once an attacker has reached code execution. A site that was probed before you patched is not necessarily compromised, but a site with an unexplained new PHP file under uploads is.

Finally, treat this as a reminder about inventory rather than about WordPress. Most organisations that run WordPress run more instances of it than they think: a marketing microsite from a campaign three years ago, a careers page, a documentation site a team stood up themselves. The update is easy. Knowing the full list is the hard part, and it is the part worth fixing before the next one of these.

Sources