WordPress 7.1.4 fixes 22 security flaws, and attackers are already trying one of them

If your website runs on WordPress, check today that it's on 7.1.4, or the fixed version for your older branch. One of the 22 flaws fixed in this release could let a stranger run code on your server, and people are already trying it.

For once the flaw isn't in a plugin. It's in WordPress itself, in the part that installs updates.

What happened

WordPress released 7.1.4 on 28 October and says it's "recommended that you update your sites immediately". Its version page counts 22 vulnerabilities.

The one that matters most is now tracked as CVE-2026-119977, rated 8.1 out of 10. During a full update, WordPress unpacks a fresh copy of itself into a folder under wp-content/upgrade. That copy includes the installer. On older versions the folder's location is predictable, and it can often be reached from the web.

So someone with no login could hit that copy in the moments while it's there, and end up running code on your server.

The catch for the attacker is timing. Wordfence, the WordPress security firm, says the window lasted "only seconds" in its lab. Patchstack, another security firm, says it "would not call it practical to exploit".

That hasn't stopped people trying. Wordfence says the first match for its new firewall rule came nine minutes after it went live. It counted more than 18,500 requests for the staged installer paths in the first 21 hours, with some sources polling small groups of sites for about 14.5 hours. When I read its post on 31 October, it hadn't reported any confirmed compromises.

Scripts can afford to wait. They just keep asking until your site happens to be updating.

Does it affect you?

Every version from 4.7 to 7.1.3 is affected. Fixes have been copied back to older branches, including 7.0.8, 6.9.11, 6.8.12 and 6.7.11, and the version page lists the rest, down to 4.7.39. WordPress says only the latest version is actively supported, though, so moving up is still the better plan.

If you're on 4.6 or older, there's no fix. That's a rebuild job, not an update.

You're on managed WordPress hosting. Your host may well have done it, but check the version yourself.

Automatic updates are on. WordPress says sites with background updates will update on their own. Check that it actually happened.

You have staff or guest writers with logins. Most of the other fixes are for cross-site scripting, where someone with a low-level account, usually Contributor or above, plants code that runs in the browser of whoever views it.

What to do this week

1. Check your version. Log in and go to Dashboard, then Updates. If you have shell access, this does the same job:

wp core version

2. Update, with a backup first. Patchstack says the window "returns on every update", so if you've got server access and can do step 3 quickly, do that first. If you can't, just update. A window of a few seconds is far better than staying on the old version.

3. Block the folder at the web server. Patchstack says a PHP firewall can't stop this, so the block goes in your web server's settings. It doesn't replace the update. On nginx, inside the site's server block:

location ^~ /wp-content/upgrade/ {
    deny all;
}

On Apache, in the site's config, with your own path:

<Directory "/var/www/example/wp-content/upgrade">
    Require all denied
</Directory>

Reload the web server, try the address in a browser (you want a 403 error), and check the site still works. If you're on shared hosting, ask your host whether it's blocked.

4. If you use the Wordfence plugin, check the firewall. Wordfence says to confirm it's optimised with Extended Protection, because the attack doesn't load WordPress in the normal way. Free users don't get the new rule until 27 November, and Wordfence says the rule "does not replace installing the security update".

5. Have a look around. Wordfence suggests this for any site that stayed unpatched. Search your logs for requests to that folder:

sudo grep -r "wp-content/upgrade" /var/log/apache2/ /var/log/nginx/

Finding requests only proves someone knocked. Successful requests for PHP files there, around the time your site updated, are what should worry you. Then check your admin users:

wp user list --role=administrator

Also look through your plugins for anything nobody installed, and for PHP files you didn't put there.

If you find something

Don't just delete it and move on. Take a copy of the site and the logs as they are, change your WordPress, hosting and database passwords, and get it looked at properly.

The bigger point

The job is knowing that the update really happened on every site, including the one nobody's logged in to since 2023. If nobody in your business is going to check that, that's what a support retainer is for. I keep your servers updated and tell you about it in plain English.