I'll update this story if CISA, WordPress or the researchers publish new details.

◢What happened

The flaw sits in the process WordPress uses to update itself. When it installs a full new version, it stages the files in temporary paths that are predictable and reachable from the internet. During that time, which WordPress calls the "upgrade window", an attacker who knows where to look can get in first and make the server run their code. Technically it is a race condition, the kind known as TOCTOU (time of check, time of use): the system checks something and, before it uses it, someone swaps it.

When it shipped the patch, the WordPress security team described it as "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window" and urged everyone to update their sites immediately, as BleepingComputer reports. The flaw was found by Umut Bayram, a researcher at Picus Security.

The NIST record scores it 8.1 out of 10, high severity. It doesn't reach critical because the attack is hard to pull off: the timing has to be right. But it needs no permissions and nobody has to click anything.

◢Is it really being exploited?

CISA gave US federal agencies until Friday, November 6 to fix it, and also requires them to carry out a forensic check to find out whether someone has already got in. Those deadlines don't apply to a European company, but they show how urgent this is.

According to The Hacker News⁵, Wordfence saw the first attack attempts nine minutes after it deployed a firewall rule for the flaw, and two of the busiest sources spent about 14.5 hours probing small groups of sites, which Wordfence links to attempts to catch the moment a site updates.

It isn't the first time this year. In July WordPress fixed another chain of flaws in its core, known as wp2shell, and according to BleepingComputer attackers started breaking into unpatched servers a few days later.

◢What we don't know

We don't know how many sites have been successfully attacked, or who is behind the attacks. No official source has attributed them to any group or country. Code its authors describe as an exploit for this flaw has appeared on GitHub, but nobody has established that it works. The researcher also says the flaw goes back to WordPress 2.7, from 2008; the official record still says it affects 4.7 onwards. Either way, 4.6 and earlier no longer get security fixes.

◢Is my site affected?

If your site, or your company's, runs on WordPress, log in to the dashboard, go to Dashboard, Updates and look at the installed version. What matters is whether it has the patch for its branch: the NIST record² lists as fixed, among others, 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11 and 6.6.11, going back to 4.7.39. If yours is older than the fixed version on its branch, it is vulnerable.

If automatic updates are on, your site may already have the patch. Don't assume it: log in and look. And bear in mind that automatic updates use the same process, so if the fix hasn't been applied yet, it's worth blocking the folder first as explained below. Many small business websites were built years ago, are looked after by an agency or a freelancer who has since moved on, and nobody knows whether they get updated. If that sounds familiar, ask whoever manages your site or your hosting provider today.

One detail matters here: even though the attack happens during an update, the answer isn't to stop updating. A site stuck on an old version piles up known flaws that attackers scan for automatically.

◢What to do now

For whoever runs the site:

• ▹Before updating, block web access to the wp-content/upgrade folder. It's the first recommendation from the researcher, Umut Bayram, because the update that installs the fix still uses the site's old code to unpack the files and, on sites running 5.9 or later, the temporary folder's name can be predicted one last time. As The Hacker News⁵ reports, WordPress works with that folder directly on disk, so blocking it doesn't break updates. On Nginx, location ^~ /wp-content/upgrade/ { deny all; } does it, and if you can only edit the .htaccess in the site root, add RedirectMatch 403 ^/wp-content/upgrade/ above the WordPress rules. Don't put the .htaccess inside that folder, because the updater empties it. Check that /wp-content/upgrade/ returns a 403 error. Running wp core update from WP-CLI doesn't avoid the problem, because it uses the same process.
• ▹Then update WordPress to version 7.1.4 or later. The other safe route the researcher suggests is a manual update: back up, unpack the new release outside the public folder, copy the core files into place without touching wp-config.php or wp-content, and run the database update. If you can't move to 7.1.4 today, at least install the patch for your branch, but treat that as a stopgap: WordPress points out³ that only the most recent version is actively supported.
• ▹Look for signs of intrusion. Wordfence suggests looking for unexpected requests to PHP files under wp-content/upgrade, PHP files in that folder nobody put there, admin accounts nobody recognises and plugins nobody installed. CISA requires this check from its agencies, so it's worth doing too.
• ▹If there are signs someone got in, change the admin passwords as well as the hosting and database passwords, and get help from someone who knows how to clean up a compromised site.
• ▹Keep a recent backup stored somewhere other than the server itself.

For management, the key question is a different one: who is responsible for keeping the website up to date? A company website is a server exposed to the internet with your company's name on it. Whoever takes it over can use it to host phishing pages, infect your visitors or steal what people type into your forms.

◢What to learn from this

I've written on this blog that most attacks come in through an email rather than through the server, and that's still true for most companies. Cases like this one, or the Ivanti VPN flaws a few days ago, are the exception worth watching: when the flaw is in something exposed to the internet, nobody has to fall for anything.

The practical lesson is to have a named person in charge of everything your company has online, and to make sure they get the security advisories. That goes for the website, the VPN and email.

If you'd like your team to understand these risks without needing to be technical, that's exactly what I cover in my cybersecurity training.