7.1.2 Patched a Hole That Reaches Back to 4.7

WordPress 7.1.2 arrived on 22 September 2026 as a security release with a single fix in it, which is usually a sign that the fix is the point. It patched CVE-2026-87902, tracked as GHSA-7hp8-65ch-5whp, and the 7.1.2 release announcement describes it as a condition where “an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories”.

What the vulnerability actually is

Read that sentence slowly, because each clause is doing work. Unauthenticated means no account is required. Page template resolution is the routine that decides which theme file renders a given page, and it takes input that can be influenced from the query string. A chosen readable local PHP file outside the active theme directories means an attacker can point that resolution at a file the theme never intended to render.

That is a local file inclusion, reached through path traversal. Whether it escalates to remote code execution depends on what happens to be on disk and readable — which is why the announcement says “under certain conditions” rather than stating a flat severity. Patchstack assigned it CVSS v4.0 9.2, critical. The credited reporter is Robert Ressl.

The practical reading is that severity varies by install but exposure does not. Every affected site can be probed for free by anyone who can send a GET request.

The back-port tells you who is exposed

WordPress fixed this in 7.1.2, 7.0.6, 6.9.9 and 6.8.10, and then kept going. Per the release announcement, the fix went to “all branches eligible to receive security fixes (currently through 4.7)”, with a backport released as 4.7.37. Patchstack puts the affected range at 4.7.0 through 7.1.1.

WordPress 4.7 shipped in December 2016. A patch that has to reach that far back is a statement about the installed base: there are enough sites running nine-year-old branches that core considered them worth the engineering. If you maintain anything on an old branch — a site left on a legacy release because a plugin broke, an internal tool nobody has touched, a staging copy still resolving on a public hostname — that is in scope, and it is the class of site least likely to have updated itself.

Probing began the same day the patch shipped

Patchstack reported that the first exploitation attempts reached its firewall at 11:49 UTC on 22 September 2026 — the same day 7.1.2 was published. The requests were shaped as a page ID plus a traversal payload in the pagename parameter, which is what an automated scan looks like when someone has read the diff and written a probe against it.

This is the argument against every patch-later policy, stated with a timestamp. The window between a public fix and a working exploit is not measured in weeks. Security patches are published with a diff, the diff shows exactly which check was added, and writing a probe from that is an afternoon’s work for someone doing it at scale. The same dynamic applies to the plugin layer, which is why what to check before you install a plugin matters more than install counts.

“Supports automatic background updates” is doing a lot of work

Minor and security releases install themselves on most sites, and the announcement says exactly that: the process begins automatically on sites that support automatic background updates. The phrase carries several conditions, and a site can fail one of them silently.

• WP_AUTO_UPDATE_CORE set to false, or DISALLOW_FILE_MODS set to true, disables core updates entirely.
• A filesystem the web server cannot write to will fail the update rather than retry it indefinitely.
• A version control directory in the WordPress root causes core to skip automatic updates by design, which catches sites deployed from git.
• A managed host may have taken over updates on its own schedule, which is usually fine and occasionally is not.

Do not infer the version from the release date. Read it: the admin footer, wp core version over WP-CLI, or the generator meta tag if it has not been stripped. The core upgrading documentation covers the manual path for anything that has fallen behind.

For the sites that cannot be updated this week, the mitigations are ordinary and partial. A web application firewall rule on traversal sequences in query parameters blocks the observed probe shape without fixing the flaw. Restricting PHP’s readable paths limits what an inclusion can reach. Neither substitutes for 7.1.2, and neither is a reason to defer it — but they buy the hours that a site with a change-control process is going to take anyway. The wider hardening layer, including the headers described in security headers worth setting and the exposure covered in what the REST API exposes by default, is worth auditing in the same pass.