WordPress 7.1.2 fixes a critical flaw that needs no password — update today

WordPress released 7.1.2 on September 22 with a single security fix, and it’s a serious one. The flaw is rated 9.2 out of 10 and carries the reference CVE-2026-87902. An attacker needs no account, no password, and nothing from you: just the address of your site.

This lands five days after the 7.1.1 release. 7.1.1 does not protect you from this one. If you updated last week and assumed you were done, you need to update again.

Am I affected?

Almost certainly, unless you’ve already updated. The flaw is present in every version of WordPress from 4.7 through 7.1.1 — nearly ten years of releases.

To check, log in and look at Dashboard → Updates, or the bottom right of the dashboard home screen, where the version number is shown.

WordPress has released a fix for every branch it still supports, so you don’t have to jump to 7.1.2 if your site is on an older line. The patched versions are 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, and so on back to 4.7.37. WordPress 4.6 and older get nothing. If that’s your site, this is the moment to deal with it.

Most sites install security releases automatically. That usually works, but “usually” isn’t “always” — automatic updates get switched off more often than people realise, and some hosts hold releases back for their own testing. Check the version yourself rather than assuming.

What it lets an attacker do

WordPress decides which template file to use for a page partly from the web address you asked for. One of the paths it built from that address was never checked for the ../ sequences that let you climb out of a folder and point somewhere else on the server. So a crafted URL could make WordPress open a file it was never meant to open.

At minimum, that means reading files off your server that should never be public. On some servers it goes further, to running the attacker’s own code, which is the worst outcome there is: new admin accounts, backdoors, redirects, spam, and anything sitting in your database.

Whether a given site can be pushed that far depends on details you probably don’t control or even know about — a setting in your host’s PHP configuration, and the folder names inside your active theme. That combination isn’t rare; it’s the default in some common hosting setups. Our advice is not to spend the afternoon working out which side of the line you’re on. Update.

Is anyone actually using it?

Scanning started within five hours of the patch going out. Patchstack saw the first probes at 17:44 UTC on the day of release.

So far those requests only look like reconnaissance — attackers checking which sites are vulnerable, not breaking into them. Nobody has published evidence of a site actually being taken over this way yet. That’s genuinely reassuring for about as long as it takes someone to write the next stage of the attack. The gap between “they’re mapping who’s vulnerable” and “they’re coming back” is normally measured in days.

What to do

1. Update WordPress now. Dashboard → Updates → Update Now. A minute’s work on most sites.
2. Confirm the version actually changed afterwards. Sites that fail an automatic update quietly are exactly the sites that stay vulnerable.
3. On an unsupported version (4.6 or older)? There’s no patch coming. Moving to a supported version is the only fix, and it’s worth planning this week.
4. Check your users list under Users, sorted by newest, for administrator accounts you don’t recognise.
5. Ask your host about their web server logs if you want certainty about whether your site was probed before you patched.

If your site was already behind and you’re now wondering whether something got in before you updated, that’s a reasonable worry and it’s answerable. Patching closes the door, but it doesn’t remove anything that walked through it first. Ask us and we’ll take a look.

On a Protect plan? Core updates are part of what we do, so this is already handled and you don’t need to act.