If WordPress has been nudging you to update this week, this is why.
WordPress 7.1.4 came out on 28 October, and it’s a security release. There are no shiny new features, just 13 fixes for problems that security researchers found and reported. The WordPress team’s advice is to update straight away, and we agree.
Your site may well have updated itself already, and if so, you can stop reading here (though we’d love it if you didn’t). But in our experience, a surprising number of WordPress websites don’t update themselves, and nobody finds out until something goes wrong. So here’s what this update is about, without the jargon, and how to check you’re covered.
If you only read one bit, read this
Get your site onto WordPress 7.1.4 today. Take a backup first, update, then check that the pages that matter most, like your checkout, donate page or contact forms, still work. That’s it. Security releases like this are about as low-risk as updates get, because they fix things rather than add things.
And if you don’t know whether your site updates itself, that’s worth finding out this week. It matters more than this particular update.
So what was actually wrong?
Thirteen fixes sounds like a lot, but most of them fall into a few groups. Here are the ones worth knowing about.
The update process itself had a weak spot
This is the big one. There was a flaw in how WordPress runs its updates which, in the window while an update was happening, could let an attacker run their own code on your server. In security terms that’s “remote code execution”, and it’s about as serious as website problems get.
Yes, there’s an irony in fixing an update problem with an update. The takeaway isn’t “updates are dangerous”, though. It’s that an update is a job to finish, not one to start and wander off from. If your site ever gets stuck on that “briefly unavailable for scheduled maintenance” message, don’t leave it for Monday.
Several ways to sneak bad code into your site
About eight of the fixes are for something called stored cross-site scripting, or XSS. The simplest way to think about it: someone finds a way to save a bit of malicious code into your site, and it quietly runs whenever someone else views that page. If the “someone else” happens to be an administrator, the code can do anything they could do, like creating new accounts or installing plugins.
These turned up in quite a few places: some of the standard blocks (Categories, Image, Playlist and the comment page links), the Interactivity API that powers interactive blocks, the Customizer’s live preview, cleverly crafted usernames, and the personal data removal tool.
That last one caught our eye. WordPress has built-in tools for handling GDPR “please delete my data” requests, and any UK organisation handling personal data, whether that’s a shop, a charity or a membership site, is likely to use them. Before this fix, those requests could be set up to carry malicious code. So a tool designed to protect people’s privacy could have been turned against the people running the site.
A couple of “private” things that weren’t
Two fixes deal with information leaking to the wrong people.
The first is that unpublished changes in the Customizer could be found by anyone, with no login needed. If you’ve ever quietly prepared a design change ahead of a product launch, a big appeal or an embargoed announcement, it may not have been quite as hidden as you thought.
The second is that editorial Notes on a post could be read by logged-in users who didn’t have permission to edit that post. If your team uses Notes for the kind of honest back-and-forth that happens before anything goes public, some colleagues may have been able to see more than you’d intended.
And some housekeeping
The rest is less dramatic. One fix stops certain saved content from being used to break pages. Another refreshes the list of security certificates WordPress trusts, after one provider’s certificates were withdrawn. That list is how WordPress makes sure it’s really talking to your payment provider, mailing list or the WordPress update servers, and not an imposter.
Won’t my site just update itself?
Possibly. Out of the box, WordPress installs security releases like this one on its own. But we regularly come across sites where that’s been switched off. Sometimes a developer turned it off years ago for a good reason that nobody remembers. Sometimes the host handles updates on its own schedule. Sometimes the server simply won’t let WordPress change its own files, or the site is set up so that updates have to go through a developer.
None of those are wrong in themselves. The problem is when nobody in your organisation knows which one applies, so everyone assumes someone else is on it.
How to check which version you’re on
The quickest way is to log in and head to Dashboard → Updates. The version you’re running is right at the top. If you’d rather not log in, or you’re checking someone else’s site, our free WP Version & Plugin Check will tell you from the outside.
If it says 7.1.4, lovely, you’re done. If not, here’s how to get there.
How to update without the drama
- Take a backup, or at least check your host’s latest automatic backup really exists. Five minutes now can save a very long afternoon later.
- Go to Dashboard → Updates and click Update Now.
- Stay with it until it’s finished. This isn’t the moment to close the tab and go and put the kettle on.
- Check the pages that matter most. Your homepage, any forms, and anywhere that takes money, whether that’s a shop checkout or a donate page. If you can, put a test payment through.
- If anything looks off, or the update won’t finish, call your developer or host. Don’t keep clicking Update and hoping.
What if we’re on a much older version?
You’re not forgotten. WordPress is backporting these fixes to every older version that still gets security patches, all the way back to 4.7. Those are being released as each one is ready, though, so you might be waiting a little while.
The honest truth is that only the latest version of WordPress is properly supported, and the backports are a courtesy. If your site is several versions behind, your plugins, theme and PHP version usually are too, and that’s a bigger worry than any one security release. (We wrote about the PHP side of this in PHP2Shell: the emergency PHP update WordPress can’t install for you.)
If you need a deadline, WordPress 7.2 is due on 8 December. Getting up to date before then is a very sensible new year’s resolution to start early.
Not the person who updates the website?
That’s completely fine. You don’t need to understand any of the above. You just need to ask whoever looks after your site three questions:
- Are we on WordPress 7.1.4 yet?
- Do security updates install automatically on our site? If not, who does them, and how quickly?
- When did we last check that our backups actually work?
If the answer to the second one is a long pause, that’s the thing to sort out. There’ll be another security release along before long, and it’s much nicer to already know who’s handling it.
Questions we usually get asked
Will WordPress 7.1.4 change how my site looks?
It shouldn’t. There are no new features, just fixes. Problems are rare, but a quick look round your key pages afterwards never hurts.
Does this mean my site has been hacked?
No. A security release means problems were found and fixed, not that anyone has used them against you. That said, if you’ve spotted anything strange, like admin accounts you don’t recognise, pages redirecting somewhere odd, or content nobody on your team wrote, get someone to take a proper look.
Do I need to update my plugins as well?
This release only covers WordPress itself, and plugins update separately. Plugins are actually where most real-world WordPress attacks happen, so while you’re on the Updates screen, have a look at what else is waiting.
Should this put me off WordPress?
Not at all. Regular security releases are what a healthy system looks like: people find problems, report them responsibly, and fixes reach millions of sites within days. The risk isn’t the software. It’s sites that never get the fixes.
Rather someone else kept an eye on all this?
Fair enough. Most people running a website have better things to do than read WordPress release notes. Keeping on top of WordPress, plugin and PHP updates is exactly what our WordPress support plans are for. We patch things proactively, check your site after every update, and you get a real person on the phone if something breaks, even on a Friday afternoon. [Optional: add a line confirming 7.1.4 status for existing support clients.]
If you’d just like someone to tell you honestly where your site stands, drop us a line. No sales pitch, promise.
Source: WordPress 7.1.4 release announcement, WordPress.org News, 28 October 2026.
