WordPress 7.1.2: A Critical RCE Fix, Five Days After the Last One

WordPress 7.1.2 was released on September 22, 2026. It fixes exactly one thing.

That’s the detail worth pausing on. Five days earlier, 7.1.1 shipped with 11 security fixes and 36 bug fixes — a normal short-cycle release, batched up and shipped together. 7.1.2 has no bug fixes, no maintenance work, nothing bundled alongside.

WordPress doesn’t cut a release for a single issue unless that issue can’t wait for the next one. The severity rating is critical, and the release was led by John Blackbourn, one of the WordPress Security Team’s most senior members.

Update now. Then read the rest, if you want to understand what you just patched.

What the vulnerability actually is

Here’s the official wording, disclosed responsibly by Robert Ressl:

An unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to remote code execution (RCE).

Three phrases in there carry all the weight. Let’s take them apart.

“Page template resolution”

When WordPress renders a page, it has to decide which file to use. A page can specify a custom template — that’s the “Template” dropdown in the page editor sidebar, the one that lets you pick “Full Width” or “Landing Page” or whatever your theme offers.

WordPress takes that value, resolves it to a file path, and includes the file. In PHP, include doesn’t just read a file. It executes it.

Normally that resolution is confined to your active theme’s directory. The vulnerability is that under certain conditions, it isn’t — the path can be steered to a readable PHP file somewhere else on the server. This class of bug is called Local File Inclusion, and it’s one of the oldest and most reliably dangerous patterns in PHP applications.

“Unauthenticated”

This is what separates 7.1.2 from almost everything in 7.1.1.

Most of last week’s fixes needed an account. Four of them needed a Contributor login, which meant your exposure depended on who you’d handed accounts to — members, freelancers, former staff. That’s a question you can actually investigate.

This one needs nobody. No login, no account, no approved comment. A request to your site is enough. Every WordPress installation on the public internet is reachable by whoever wants to send one, and automated scanners send millions.

“Can lead to remote code execution”

RCE is the top of the severity scale. Not a data leak, not a defaced page, not script running in someone’s browser. Code running on your server, with whatever permissions your web server process holds.

From there, everything else follows: reading wp-config.php and the database credentials inside it, writing a backdoor into a plugin folder, harvesting customer data, adding an administrator account. It’s the starting point for the kind of incident we wrote about in what to do in the first hour after a hack.

“Under certain conditions” — and why that isn’t reassuring

This is the phrase people latch onto, and it’s the one most likely to get someone in trouble.

The advisory says pre-conditions must be met for both the server environment and the active theme. That’s genuinely true. Not every site is exploitable.

But look at what you’d need to know to rule yourself out. You’d have to understand exactly which PHP configuration settings matter and how your host has them set. You’d have to audit how your theme handles template resolution — including any child theme, any page builder that hooks into template loading, and any plugin that filters it. Then you’d have to be confident none of that changes the next time something updates.

Security advisories are deliberately vague about pre-conditions, and for good reason: the full detail is a recipe. Researchers publish enough to justify the severity and not enough to weaponise. The tradeoff is that site owners can’t self-assess.

So the honest position is this. You probably aren’t exploitable. You can’t demonstrate it, the people who can are already reverse-engineering the patch, and the update takes two minutes.

Further detail is tracked as CVE-2026-87902 / GHSA-7hp8-65ch-5whp.

The backport problem

One line in the release notes deserves more attention than it usually gets:

As a courtesy, the security fix is being backported to all branches eligible to receive security fixes (currently through 4.7). The backports are in progress and will ship as they become ready.

Read that carefully. In progress. As they become ready.

If your site runs an older WordPress branch — and plenty do, usually because someone was afraid an update would break something — you are not necessarily patched yet. You’re waiting, while the patch for the current branch is public and readable by anyone who wants to work backwards from it.

That gap is the whole argument against staying on an old version. The vulnerability becomes public knowledge on release day. Your fix arrives whenever it arrives. And WordPress is explicit that only the most recent version is actively supported; the backports are a courtesy, not a guarantee.

What to do, in order

Update to 7.1.2. Dashboard → Updates → Update Now. If automatic background updates are enabled, this may already have happened — verify rather than assume.

Confirm the version actually changed. Still on the Updates screen. An interrupted update can report a new version number while the old files remain in place, which is one of the quieter ways sites stay vulnerable after their owner believes they’re patched.

Load the front end and the block editor. A single-fix security release is about as low-risk as WordPress updates get, but 7.1 substantially reworked the editor and 7.1.1 added 19 more editor fixes on top. A thirty-second check costs nothing.

Check your PHP error log. Silent failures live here and nowhere else.

If you run a store: stage it first. Copy to staging, update, place a test order, confirm it lands in the admin and the confirmation email sends. Then deploy. Core updates rarely break checkout — but when they do, nothing on the site looks wrong, and you find out from a customer two days later.

If you’re on an older branch: don’t wait for the backport. Get current.

What this week actually demonstrates

Two security releases in five days. Eleven fixes, then one critical one. Neither was predictable, and neither waited for a convenient moment.

That’s the part worth internalising. Security releases don’t arrive on a schedule you control. They arrive when a researcher finds something, and the window between public disclosure and automated exploitation is now measured in days — sometimes hours.

A site that gets updated “when someone remembers” is a site that will eventually be behind during one of those windows. Not through negligence. Just through the ordinary reality of running a business and having other things to do on a Tuesday.

The short version

WordPress 7.1.2 fixes one critical vulnerability: unauthenticated local file inclusion in page template resolution, leading to remote code execution under certain server and theme conditions. CVE-2026-87902.

No login required. RCE is the top of the severity scale. The pre-conditions are real but unverifiable from your side, so the only sensible assumption is that you’re affected.

Update immediately, confirm the version changed, check the front end and the error log. Stage it first if you run a store. And if you’re on an older WordPress branch, the backport hasn’t necessarily reached you yet — that’s a reason to get current, not a reason to wait.

 

Not sure whether your site is patched, or running an old version you’re afraid to update? Get in touch — phone, email or live chat. We do exactly this.

Two critical security releases in five days is the clearest case for maintenance we could make. Our WordPress Maintenance package is $69/month, fixed: security releases applied the day they ship, staged and tested first, with offsite backups and monitoring. For WooCommerce stores it’s $89/month, including test transactions through your real payment gateways.

You shouldn’t have to know that 7.1.2 happened.

WPerizo.com — WordPress & WooCommerce. Nothing else. 🦔

Share this :

Leave a Reply