Last Tuesday, 28 October, WordPress released version 7.1.4. It’s a security update that fixes 22 vulnerabilities. Most of them are the routine kind, but one is a flaw in WordPress’s own update process. It could let someone run their own code on your server without logging in, and attackers started trying it within minutes of the fix being made public.
If your site updates itself automatically, you’re probably fine. “Probably” is carrying a lot of weight there, so here’s what happened, which sites are most at risk and what to check this week.
What WordPress 7.1.4 fixes
According to the official WordPress 7.1.4 release notes, the update fixes 22 vulnerabilities. The WordPress team’s advice is blunt: “Because this is a security release, it is recommended that you update your sites immediately.”
Most of the fixes are for cross-site scripting (XSS). In plain English, someone who already has a login to your site, such as a contributor or author, could hide malicious code in a post or block, and that code would then run in the browser of anyone else who views it, including you. That’s a real risk if several people log in to your site, but it isn’t the headline.
The headline is what the release notes call “a race condition during core updates that could lead to remote code execution”, reported by researcher Umut Bayram. “Remote code execution” means an outsider can make your server run their code, which is about as bad as website security gets.
The fixes have also been backported (applied to older versions) for every branch back to WordPress 4.7. So if you’re on 7.0 the fixed version is 7.0.8, for 6.9 it’s 6.9.11, and so on. WordPress 4.6 and older get no fix at all.
How the WordPress update flaw works
When WordPress does a full update of its core files, it first unpacks a complete fresh copy of WordPress into a temporary folder inside wp-content/upgrade, then moves the files into place. That copy includes the installer script that you see when you first set up a WordPress site.
Before 7.1.4, those temporary folders had predictable names. On many servers, PHP files in that folder can be run directly from the web. So for the few seconds the copy exists, an attacker who requests the staged installer at the right moment could take over the server, with no login and none of WordPress’s usual permission checks.
The fix gives the temporary folders random names and adds some extra safeguards. There’s an irony here, though: installing 7.1.4 is itself a core update, so the window opens one last time while you apply the fix.
The flaw is rated 8.1 out of 10 (“high” rather than “critical”) because the attacker has to hit a gap that lasts only seconds. That’s less reassuring than it sounds. They don’t need luck, they just need to keep trying, and automatic updates give them a rough idea of when to try.
Is it being exploited?
Here’s what has been reported and what hasn’t.
Wordfence, which makes one of the most widely used WordPress security plugins, says it added a firewall rule for this flaw at 20:30 UTC on release day and saw the first matching attack attempt nine minutes later. In the first 21 hours it counted more than 18,500 requests aimed at staged installer paths. Two of the busiest sources kept polling small groups of sites for around 14.5 hours, which looks very much like someone waiting for an update to start. (Figures as reported by GBHackers and Brandefense.)
What isn’t confirmed: as of 31 October, Wordfence had reported exploitation attempts, not confirmed successful hacks. Attackers are trying it in large numbers, but nobody has published evidence of sites being taken over through this flaw. I’d still treat it as live.
There’s another catch. The attack goes straight to a file, which means WordPress itself never loads, so security plugins that run inside WordPress may not see it happen at all. The evidence would be in your server’s access logs, not your plugin’s dashboard.
Which WordPress sites are most at risk
WordPress applies minor security releases like this one automatically on most sites, and the release notes confirm that sites with automatic background updates will start updating on their own. Most sites will have quietly moved to 7.1.4 already. The ones I’d worry about are:
- Sites where automatic updates have been switched off, either by a plugin or by a setting a developer added years ago and everyone has forgotten about.
- Sites on hosting that holds core updates back “for testing” and hasn’t released them yet.
- Sites where the automatic update failed (a full disk or wrong file permissions are the usual causes) and nobody noticed.
- Sites on WordPress 4.6 or older, which won’t get a fix at all.
If nobody is actively looking after your site, there’s a fair chance you don’t know which of these applies to you. That’s the real problem.
What to check on your WordPress site now
- Check your version. Go to Dashboard > Updates. You should be on 7.1.4, or the patched release for your branch (7.0.8, 6.9.11, 6.8.12 and so on). Don’t assume the automatic update worked: check.
- Update if you’re not. Ideally, ask your host or developer to block PHP from running inside the wp-content/upgrade folder first, and to leave that block in place afterwards. Several security write-ups recommend it, and it closes the gap during the update itself.
- Look for anything unfamiliar. If your site wasn’t patched on 28 October, check Users for administrator accounts you don’t recognise, and Plugins for anything you didn’t install.
- Ask your host to check the access logs for requests to PHP files under wp-content/upgrade. Your security plugin may not have recorded them.
- Update your plugins and themes as well. Core automatic updates don’t cover them unless you’ve turned that on separately.
- Confirm you have an off-site backup from before 28 October, just in case.
- Don’t rely on a firewall alone. Firewall rules are a useful extra layer, but updating is the only real fix. The free version of Wordfence also gets new firewall rules later than the paid one.
Why a hacked site is an SEO problem too
This isn’t only a security issue. When a site is hacked, the usual aim is to use it, not to wreck it: spam pages, hidden links and redirects to dodgy sites, all quietly piggybacking on the trust you’ve built with Google.
If Google spots it, your pages can show a warning label in search results, and browsers can show a full-page warning before anyone reaches your site, as described in Google’s Security Issues report documentation. Few people click past a warning like that. Cleaning up is the easy bit. Earning back rankings and customer trust takes much longer, and AI assistants are no more keen than Google to recommend a site that’s been serving malware.
So it’s worth logging in today to check, even if you think everything updates itself.
Let me look after it for you
Flaws like this are exactly why I don’t think WordPress should be left to look after itself. My WordPress Support & Hosting packages (from £89+VAT a month) include hosting on servers I manage myself, WordPress, theme and plugin updates, and daily backups stored off-site. When something like 7.1.4 comes along, I deal with it and you carry on running your business. Some packages also include an ongoing SEO and AI search (GEO) campaign.
There are no calls and no sales meetings. Order online and I’ll get started.
Peter Mahoney
WordPress SEO & AI Search (GEO) Expert