WordPress 7.1.2 Patched a Critical RCE Flaw: What I Did to Every Site I Manage

If you run a WordPress site, stop what you are doing and check your version. On September 22, 2026, the core team shipped WordPress 7.1.2, and it is not a routine maintenance bump. It closes a critical flaw, tracked as CVE-2026-87902, that lets an attacker who has never logged in run code on your server under the wrong conditions. I spent the better part of a day pushing this update across the client sites I manage, and I want to walk you through what the bug actually is, who is at risk, and the exact steps I took so you can protect your own site today.

What CVE-2026-87902 actually does

The vulnerability lives in the way WordPress decides which template file to load for a page. When core resolves a page template through get_page_template(), an attacker can influence that resolution and point it at a readable PHP file that sits outside your active theme directories. In plain terms, this starts as a path traversal, a local file inclusion, and if the server and theme line up in a certain way, it turns into full remote code execution.

The security researcher Robert Ressl disclosed it, and it carries a CVSS v4 score of 9.2, which sits firmly in the critical band. The part that makes me nervous is the word “unauthenticated.” An attacker does not need an account, a password, or any foothold. They just need your site to be running vulnerable code and to meet the preconditions. Patchstack published a clear technical breakdown of the LFI to RCE chain if you want the deep version.

Who is actually affected

Here is the uncomfortable news. The flaw reaches all the way back to WordPress 4.7, so this is not a “only the newest sites” problem. The core team backported fixes to every supported branch down to 4.7, which tells you how seriously they took it.

Whether the local file inclusion escalates to code execution depends on your active theme and your server setup. The affected list includes the legacy Twenty Twelve and Twenty Fourteen bundled themes, and it also names some widely used third party themes such as Neve, Hestia, and Sydney. Those three are not obscure. They ship on a huge number of small business and agency sites, which is exactly the audience I work with every week. Even if your theme is not on the list, I would not treat that as a free pass. The safe assumption is that any site below 7.1.2 needs updating now, and you sort out the theme details afterward.

The steps I took on every site

I do not just click “Update Now” and walk away, especially on a security release where attackers are already probing sites within hours of disclosure. Here is the sequence I follow, and it is the same one I described in my safe-update playbook from the 7.0.3 XSS release.

1. Take a real backup first

Before touching core, I take a full backup of files and database and I make sure I can actually download it, not just trust that it exists on the server. A backup you cannot restore is a decoration. If the update goes sideways on a fussy theme, this is your undo button.

2. Update on staging when the site is complex

For simple brochure sites I update production directly after the backup. For stores and membership sites with heavy theme and plugin stacks, I clone to staging, run 7.1.2 there, and click through the key flows before I touch the live site. Ten minutes on staging beats an afternoon of emergency debugging.

3. Push core to 7.1.2

From the dashboard, go to Updates and run the core update, or download the release directly from WordPress.org. Confirm the version number afterward under Dashboard and Updates. Do not assume it worked because the page did not error. Verify the number reads 7.1.2.

4. Check your theme and swap if needed

If you are on Neve, Hestia, Sydney, or one of the old bundled themes, update the theme to its latest version as well, since theme authors have been shipping their own hardening alongside the core fix. If you are still running Twenty Twelve or Twenty Fourteen on a live site in 2026, that is a good moment to move to something maintained.

5. Look for signs you were already hit

Because this bug was public and being probed quickly, I do not assume a clean site just because the patch is in. I scan for unfamiliar PHP files, check for admin users I did not create, and review access logs for odd requests against template parameters. If anything looks off, my guide on spotting a hacked WordPress site walks through the checks I run and what to do if you find something.

Why this keeps happening, and how to stop reacting

This is the third serious WordPress core security release I have written about in recent months, after the 7.0.2 wp2shell exploit earlier this cycle. The pattern is always the same. A flaw gets disclosed, a patch ships, and the sites that get compromised are the ones sitting two or three versions behind because nobody was watching.

The fix is not heroic. It is boring, consistent maintenance. I keep automatic updates on for minor and security releases across the sites I manage, I run a monthly check even on the ones that auto update, and I keep the underlying stack healthy so updates apply cleanly. If you want to understand how the template system I mentioned earlier actually resolves files, the WordPress template hierarchy documentation is worth twenty minutes. Understanding how a feature works is the first step to understanding how it breaks.

Performance and security are also more connected than people expect. A well maintained site with a lean plugin list and proper caching is easier to update, easier to monitor, and gives an attacker fewer places to hide. I made that case in detail in my post on why your site needs a persistent object cache, and it holds up here too.

Do this today

If you take one thing from this post, make it this. Log into your dashboard, check your version, and if you are below 7.1.2, back up and update now. This is a critical, unauthenticated flaw with a public patch, which is the exact combination attackers love. The update takes minutes. Cleaning up after a compromise takes days, and sometimes it costs you the site.

If you manage more than a couple of sites and you would rather not track every core release yourself, that is a large part of what I do for clients. I keep WordPress and Shopify builds patched, monitored, and fast so you can focus on your business instead of your version numbers.