The WordPress updater flaw is now on the US government's exploited list. Check your site

The WordPress flaw I wrote about last Friday has moved up a level. CISA, the US government's cyber security agency, has added it to its list of flaws known to be used in real attacks.

If your site is on WordPress 7.1.4, good. But this is the one flaw where updating is also the risky moment, so it's worth a second look even if you've already done it.

What's changed

The flaw is CVE-2026-119977. On 3 November CISA added it to its Known Exploited Vulnerabilities catalog. That list is what US federal agencies have to patch by a deadline, and this one's deadline is tomorrow, 6 November.

CISA's entry describes it as a race condition that "could allow unauthenticated attackers to execute code on the server during the upgrade window". In plain English: a stranger with no login can try to hit a temporary copy of the WordPress installer in the few seconds while your site is updating itself, and if they win the race, run their own code on your server.

The entry also points agencies to CISA's forensic triage requirements, not just the patch. My reading of that is simple. Don't just update. Check whether anyone got in.

CISA doesn't say who's being attacked or how many sites, and I haven't found a public report of confirmed break-ins. When I wrote last week, Wordfence had already counted more than 18,500 requests for the installer paths in the first 21 hours. Being on CISA's list is a step on from that. It means CISA treats it as a flaw being exploited, not just scanned for.

Does it affect you?

Every WordPress version from 4.7 to 7.1.3 is affected. The fix is in 7.1.4, released on 28 October, with fixed versions for older branches too (7.0.8, 6.9.11 and so on, down to 4.7.39).

• Sites still on an old version. These are the obvious ones. Every future update is a chance for the attack, and so is the one you haven't done yet.
• Sites that updated after 28 October. Your site went through the risky window at least once, while people were already scanning for it.
• Sites that will update again. WordPress 7.2 is due on 8 December. Patchstack said last week the window "returns on every update", so blocking the folder still matters after you've patched.

If you're on WordPress.com or a fully managed WordPress host, ask them whether they've blocked the upgrade folder. You probably can't do it yourself.

What to do this week

1. Check your version. Dashboard, then Updates, or on the server:

wp core version

2. Block the upgrade folder at the web server, if you haven't. This was step 3 last time and it's now the most useful thing on the list, because it protects the next update as well as this one. 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, then visit https://yoursite/wp-content/upgrade/ in a browser. You want a 403 error back.

3. Look back through your logs. This is the new bit. Find when your site updated, then look for requests to the upgrade folder around that time:

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

On Ubuntu and Debian, older logs get compressed, so check those too:

sudo zgrep "wp-content/upgrade" /var/log/nginx/*.gz /var/log/apache2/*.gz

Lots of requests that got a 404 or 403 just mean someone knocked. What you're looking for is a 200 response for a PHP file in that folder, especially within a minute or so of your update.

4. Check for things you didn't add. List your admin users and look for anyone you don't recognise:

wp user list --role=administrator

Then look for PHP files somewhere they shouldn't be, such as the uploads folder:

sudo find /var/www/example/wp-content/uploads -name "*.php"

There usually shouldn't be any. A few plugins leave an empty index.php in there, which is harmless, but anything else is worth opening and reading.

If you find something

Don't delete it and carry 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.

If WordPress isn't the whole story

Plenty of businesses have a WordPress site sitting next to something bespoke: a booking system, a customer portal, an old PHP app that nobody likes touching. The team at Dev Partners wrote today about why old PHP apps are still the problem after PHP2Shell, and they look after that kind of code month to month.

The bigger point

This is my third "now being exploited" post in a fortnight, after Brotli and GitLab. The pattern's the same each time: a fix comes out, someone updates, and a week later it turns out the update was only half the job. The other half is checking nothing happened before you got there, and making sure the next update is safe too.

If nobody in your business is going to do that, that's what a support retainer is for. I keep your servers updated, check the logs when something like this comes up, and tell you about it in plain English.