WordPress 7.1.2: Critical Core Flaw, No Login Needed

Good evening. We have some breaking WordPress security news. If you manage a WordPress website, update WordPress now.

A critical vulnerability has just been disclosed in WordPress itself. Not a plugin, not a theme, but WordPress core, and it has just been given a severity score of 9.2 out of 10. But there’s an important detail here: this does not mean that every vulnerable WordPress website can automatically be taken over.

There are specific conditions required before this vulnerability can become a remote code execution. I’ve spent 25 years building production software and I manage WordPress websites for businesses. So let me explain what has actually happened, who needs to take action, and what I would be checking on a business website today.

WordPress has disclosed a critical security vulnerability identified as CVE-2026-87902. The problem is what’s known as a path traversal vulnerability. WordPress has functionality that works out which PHP template file should be used to display a page.

The vulnerability could allow someone on the internet, without logging into WordPress, to manipulate that process and potentially make WordPress include a readable PHP file from outside the normal theme directories. That is already serious, but under the right conditions, it can become much worse.

Think about what PHP files actually are. They aren’t just documents; they contain code that your web server can execute. So imagine an attacker can influence which PHP file WordPress loads.

If the right PHP file already exists on that server and the website and theme meet the necessary conditions, the attacker may be able to turn this vulnerability into remote code execution. In plain English, that could potentially mean running their own instructions on your website.

And once someone can execute code on a server, we’re no longer talking about somebody changing a page. We’re potentially talking about access to information, modification of the website, or taking the website offline. That’s why this vulnerability has received a critical rating.

And this is where I don’t want people panicking: the vulnerability does not mean every WordPress website can immediately be taken over. The official WordPress advisory says specific preconditions must exist in both the server environment and the active WordPress theme before this becomes remote code execution. Now, that’s important.

So there are two statements that can both be true. This is a critical WordPress vulnerability, and exploitation still requires particular conditions on the target website.

What makes this something I would act on immediately is that an attacker doesn’t need an administrator account. According to the advisory, they don’t need a subscriber account, they don’t need to authenticate at all, and they don’t need someone to click a malicious link.

So I wouldn’t be spending today trying to determine whether my particular configuration is exploitable before installing the update. I’d patch first.

This is also unusual because we’re not talking about one recent WordPress release. WordPress lists affected versions across branches going all the way back to WordPress 4.7. That includes WordPress 7.1, 7.0, 6.9 and numerous older branches.

So if you’re responsible for a company WordPress website, don’t assume you’re safe because you haven’t installed the latest major version. WordPress has released patch versions for all of those affected branches. For the current 7.1 branch, the patch release is WordPress 7.1.2.

First, back up your website, database and files. Then update WordPress core to the patch release available for your branch. If you’re currently running WordPress 7.1.1, that means moving to 7.1.2.

Then confirm the update actually completed. Don’t just press the button and assume everything worked. Check the WordPress version, load the public website, and check your important forms, checkout, login and any critical business functionality.

And if your website is significantly behind or you’re unsure whether it’s safe to update, get whoever manages the website involved rather than simply leaving it vulnerable. whoever manages the website should be handling exactly this kind of update.

Now, there’s one more distinction that’s really important. Updating a vulnerable website fixes the vulnerability. It does not tell you whether somebody exploited it before you updated.

Think of it like discovering your office door was unlocked overnight. Locking the door this morning is absolutely the first thing you should do. But locking it doesn’t tell you whether somebody came inside while it was open.

At this stage, a vulnerable version does not automatically mean your website has been compromised. But for important business websites, I’d be paying attention to security logs, unexpected file changes, new or unusual administrator accounts, and anything else that could indicate suspicious activity.

Now, this one matters because it’s in WordPress core itself. The vulnerability is critical, it can be reached without authentication, and under the required conditions it can potentially lead to remote code execution. But those conditions matter, and vulnerable does not automatically mean compromised.

So don’t panic. Patch the vulnerability, verify the update, and then determine whether there’s anything else you need to investigate.

I’ll keep watching this advisory, and if we get evidence of exploitation in the wild or more information about exactly which configurations are exposed, I’ll update you here.