WordPress 7.1.2 Patches an Unauthenticated LFI That Can Hit RCE

WordPress 7.1.2 shipped on September 22 with exactly one fix, and it's a serious one. An unauthenticated attacker can manipulate page-template resolution into loading a local PHP file from outside your theme's directories, and on a specific class of themes that file-read turns into full remote code execution, no login required at any step.

• The flaw, CVE-2026-87902 (GHSA-7hp8-65ch-5whp), scores 9.2 on CVSS 4.0 and needs no authentication to trigger.
• It affects WordPress Core from 4.7.0 through 7.1.1, close to a decade of releases, and is fixed only in 7.1.2.
• Unauthenticated file inclusion works on every affected site. Remote code execution only follows if the active theme has a top-level folder whose name starts with page-, such as page-templates.
• Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney all ship that folder pattern, which is why theme choice, not just plugin count, decides how bad this gets for a given site.

What WordPress actually patched

The bug sits in get_page_template(), the function WordPress core uses to decide which template file renders a given page. Reporter Robert Ressl found that the value feeding that resolution isn't checked closely enough before it becomes a filesystem path. Send the right crafted value and the function reaches outside the theme folder it's supposed to stay inside, pulling in any readable .php file on the server. No credentials, no cookies, nothing. The GitHub advisory lists johnbillion as the reporter of record on the wordpress-develop security tracker, and the classification is CWE-98, improper control of filename for an include statement: the textbook shape of local file inclusion.

RelatedN-able N-central Hit by CVSS 10.0 Pre-Auth RCE Flaw

Am I actually exploitable, or just exposed?

Here's the nuance most coverage of this CVE will skip past on the way to "patch now," which is correct advice but thin reporting. One advisory, two different outcomes, and they matter a lot for how urgently you act.

Unauthenticated file inclusion works on every site running WordPress 4.7.0 through 7.1.1, regardless of theme. An attacker who triggers it can read any file the web process can open, typically including wp-config.php: database name, username, password, secret keys, all of it. That's serious on its own, no RCE required.

Remote code execution is the second, conditional stage. It only fires when the active child or parent theme has a top-level directory starting with page-. The bundled legacy themes Twenty Twelve and Twenty Fourteen use that pattern, along with three widely installed third-party themes: Neve, Hestia and Sydney. On those sites, the same traversal that only leaks a config file elsewhere gets steered into including and executing attacker-controlled PHP, a much shorter path to a fully compromised server.

What does the page- directory have to do with it?

Themes traditionally group custom page templates into a folder like page-templates/ so get_page_template() has somewhere expected to look. That's ordinary theme structure, not a misconfiguration. The same lookup logic that finds legitimate templates there can be tricked into resolving a traversal path that lands elsewhere, and if the folder exists, the code path that turns a read into an execution is already wired up and waiting.

How to check your own site in under a minute

You don't need a scanner. Open a file browser or SSH session and check two places: wp-content/themes/<your-active-theme>/ and, if you run a child theme, its parent's folder too. Look for any top-level directory starting with page-. Found one? Treat your site as exploitable for code execution and update now. Found nothing? You're still exposed to unauthenticated file disclosure, enough to hand an attacker your database credentials, so "my theme is clean" isn't a reason to wait on 7.1.2. It changes how bad the worst case is, not whether you need the patch.

RelatedSAP Commerce Cloud RCE hit by attacks 3 days after patch

Why did this survive since 2016?

WordPress 4.7.0 shipped in December 2016, and that's how far back the affected code goes: nearly a decade of releases carrying the same bug. Template resolution tends to get treated as theme plumbing rather than input handling during security review. It's not a login form or a REST endpoint, just the quiet function that decides which file to load before a page renders. But structurally it does exactly what a classic LFI bug does: takes a value influenced by the request and turns it into a filesystem path. That shape is dangerous no matter how internal the code feels, and it's an easy surface to underweight when triaging where the next audit should look.

1. Dec 2016 WordPress 4.7.0 ships introduces the page-template resolution code path that carries the flaw
2. 22 Sep 2026 GHSA-7hp8-65ch-5whp published, WordPress 7.1.2 released security-only release closes CVE-2026-87902

Scale is the other reason this matters beyond any one site owner. WordPress runs a large share of the web, and a critical, unauthenticated bug on software that common turns into a mass-scanning event within days, not weeks. Attackers don't need to target you specifically, just a list of URLs and a script.

Our take

The most useful thing about this advisory is that WordPress didn't just say "critical, patch now" and stop there. The chain is documented precisely enough that a site owner can self-diagnose in under a minute instead of waiting on a scanner or a vendor blog post, and that's worth more than the CVSS score by itself. Most outlets will run the 9.2 and the phrase "unauthenticated RCE" and move on, which isn't wrong, but it flattens the one distinction that actually changes what a reader should do next: whether their theme ships a page-* folder. Report that, and a stressed admin triages in a minute instead of guessing.

Original analysis by GenZTech, based on the WordPress security advisory and the 7.1.2 release notes.