WordPress 7.1.2: Unauthenticated LFI in Template Resolution (CVE-2026-87902)

WordPress 7.1.2 shipped on September 22, 2026, five days after 7.1.1. It contains a single security fix, rated critical: an unauthenticated local file inclusion in page template resolution that can escalate to remote code execution where the pre-conditions are met. Tracked as CVE-2026-87902 / GHSA-7hp8-65ch-5whp, reported by Robert Ressl, release led by John Blackbourn.

The Vulnerability

From the WordPress security team’s disclosure: an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories. Where the relevant pre-conditions in both the server environment and the active theme are satisfied, this can lead to remote code execution.

Read against the way most WordPress security issues are shaped, three properties stand out.

• Unauthenticated. No account, no nonce, no privilege level. This is the single most important attribute for triage. In 7.1.1, ten of eleven fixes required Contributor-level access or above. Here the barrier is zero.
• Local file inclusion, not upload. The attacker selects a readable PHP file already present on the server. That reframes exposure: anything that writes attacker-influenced content into a readable PHP file anywhere on disk becomes a viable second stage. Shared hosting, verbose logging into PHP-parsed paths, and permissive upload directories all become relevant.
• Conditional. Exploitability depends on the server environment and the active theme’s template resolution behavior. This genuinely narrows the affected population.

The conditionality is the part worth handling carefully. It is a real constraint, not marketing language. It is also not something most operators can evaluate per-site with confidence, because it turns on PHP configuration and theme internals rather than anything surfaced in the admin. Treating “conditional” as “probably not us” is the wrong inference to draw.

Triage Across a Portfolio

Unauthenticated pre-auth RCE with a public CVE and a published advisory does not permit a staged rollout over a fortnight. Patch everything, prioritising by what shortens the window.

Patch first: anything with a custom or heavily modified theme, since the vulnerability lives in template resolution and non-standard resolution logic is exactly where the pre-conditions are least predictable. Then anything on shared hosting, where readable PHP files outside your own tree are more plentiful.

Patch next: sites accepting file uploads of any kind, and sites with permissive filesystem permissions. Neither is required for the vulnerability, but both improve an attacker’s odds of having a useful file to point at.

Standard cycle: everything else, which is still today rather than next week.

Sequencing

This is a small, targeted release, so the patch itself is low-risk. The discipline worth keeping:

1. Snapshot before, verified restorable. Backups you have not tested are assumptions.
2. Update core and themes together. The flaw concerns theme template resolution, so a stale theme is not a neutral variable in this particular release.
3. Confirm the reported version afterward. Do not trust the update’s own success message. Failed background updates are quieter than most people expect, particularly where file permissions have drifted.
4. Audit readable PHP outside theme directories while you are there. Forgotten installs, old backup directories, and vendor trees left in the web root are all candidate targets for an LFI. This is worth doing once properly rather than in response to each advisory.

Two Releases in Five Days

WordPress 7.1.1 landed September 17 with eleven security fixes. WordPress 7.1.2 landed September 22 with one. The second is the more urgent, and any triage process that ranks by fix count rather than by privilege requirement will get that ordering backwards.

It is also a reminder that “we patched last week” is not a position. The 7.1.1 release does not contain this fix, because this issue was not yet public when it shipped.

Backports and Older Branches

The fix is being backported to all branches still eligible for security updates, currently reaching back to 4.7, shipping as each becomes ready rather than simultaneously.

The same caveat applies as last month, and it is worth repeating because backports are routinely misread as reprieves. A backport closes this specific vulnerability on an old branch. It does not confer support status, and it does not address the accumulated difference between that branch and current. For any site still parked on 6.x, this release is a prompt to schedule the upgrade path, not evidence that staying put is viable.

Frequently Asked Questions

Managed Patching, Without the Tracking

Two urgent releases in five days, with the smaller one carrying the greater risk, is a fair test of whether update management is a process or a reaction. Reading the advisory, correctly ranking it against last week’s, and knowing which sites in a portfolio carry the exposure is the actual work.

Maintenance Press treats WordPress releases as a managed cycle: regular security patching, managed WordPress security, verified backups before every change, and expert support when a release behaves unexpectedly.

See our WordPress maintenance plans, or request a quote and tell us what you are running.