On 28th October 2026, WordPress published a security release, version 7.1.4. The flaw it fixes lives in the way WordPress updates itself, which means that installing the fix is also the one moment the flaw can be used against you. That is unusual enough to be worth explaining slowly, and the explanation turns out to be reassuring rather than alarming. The fix is real and it works, the dangerous moment is brief, and on a great many sites it has already come and gone automatically, overnight, without anyone noticing it was there.
The dates, in order
WordPress 7.1.4 arrived on 28th October 2026 as a security release, and the first item in its own list of fixes describes the problem plainly: a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window, reported by Umut Bayram.[1] Remote code execution is the serious kind of flaw: it means an attacker getting the server to run instructions of their choosing, rather than simply reading something they should not.
Six days later, on 3rd November 2026, the United States Cybersecurity and Infrastructure Security Agency, CISA, added the flaw to a list it keeps called the Known Exploited Vulnerabilities catalogue, and gave United States federal agencies until 6th November to fix it.[2] That catalogue is worth understanding, because a place on it carries a specific meaning. CISA only adds a flaw once it has evidence the flaw is being used in real attacks, not merely that it could be one day. The flaw is tracked as CVE-2026-119977, and CISA records it as a time-of-check to time-of-use race condition, which is the technical heart of the story.
What actually goes wrong
When WordPress updates itself from a complete package, it does something sensible. It unpacks a copy of the new version into a temporary folder inside wp-content/upgrade, works with that copy, and then swaps it into place. The difficulty is that this temporary copy includes the WordPress installer, and on most servers the folder it sits in can be reached from the web.
CISA describes the cause as predictable, web-accessible staging paths used during full-package core upgrades, and that phrase contains the whole problem.[2] The folder’s name can be worked out in advance, the web server can reach it, and for a few seconds during an update the installer is sitting there. An attacker with no account at all, who reaches that installer in the short window before WordPress deletes the copy, can end up running their own code on the server. The gap being exploited is the one between the moment WordPress checks the copy and the moment it uses it, which is what a time-of-check to time-of-use race condition means: two things that are each safe on their own become unsafe in the instant between them.
So the window of exposure is not the old version sitting quietly on your site. It is the act of updating.
The mitigation points at the server
There is a sensible mitigation beyond the update itself, and it points straight at where this problem is solved. Because the danger is a web-accessible folder, the remedy is to make the wp-content/upgrade folder unreachable from the web while an update runs, which closes the short window an attacker needs. It is a change made at the server, not a switch in a hosting dashboard, and it is not something to attempt blind on a live site. It belongs to whoever looks after the server, which is the point the rest of this article arrives at.
Who is affected
The fix shipped in WordPress 7.1.4, and WordPress also backported it to every older branch still eligible for security fixes, which currently reaches back as far as version 4.7, with those backports shipping as they became ready.[1] In plain terms, that is very nearly every WordPress site that has not already updated. The practical question is not whether your version appears on some list, but simply whether it has reached 7.1.4 yet.
Serious on paper, hard in practice
It is worth holding two true things together here rather than picking one. The flaw carries a high severity score, 8.1 out of 10, in the record kept by Wordfence, the security firm that assigned it, and CISA lists it as actively exploited, which is the only reason anything joins that catalogue.[3] Yet the same sources show why it is hard to use. That severity record marks the attack as high in complexity, and CISA’s own assessment is that it cannot be automated.[3] A race condition that depends on precise timing is genuinely difficult to land against any single site, and at the same time well worth attempting when the number of possible targets runs into the millions. Long odds against one site and a real problem across all of them are not a contradiction.
What to do, in one look
Open the WordPress dashboard, go to Updates, and read the version number. If it says 7.1.4 or later, this is already behind you and nothing more is needed. If it does not, the update still needs doing.
There is a quieter point folded into that instruction. Many sites have automatic updates switched on, and will have taken 7.1.4 by themselves during the night, which means the dangerous window opened and closed while the owner slept and never knew it existed. That is not a reason for alarm. It is a reason to care who was watching the server while it happened.
Where we come in
This is the kind of flaw that shows what a managed platform is actually for. Every sensible precaution here, denying web access to that upgrade folder for the length of an update, choosing a quiet moment to run it, and confirming that a backport really reached an older branch, is a job done at the server, and none of it is something a site owner can realistically do from inside WordPress.
On our WordPress hosting, WordPress core security releases like 7.1.4 are applied by us, on every WordPress package we offer. So for the flaw in this article, the update and the server-side care around it are already ours to carry, not yours. Plugin updates remain in your hands, unless you are on our fully managed Concierge hosting, where we look after the whole of your site.
If you would like to know exactly how your plan handles WordPress core and plugin updates, that is a fair thing to ask before you need the answer rather than after.
The useful question to put to any host is not whether they keep WordPress updated, but what they do to the server while the update is running.
Related reading
- A WordPress security plugin’s flaw was hiding in its own traffic log
- WordPress 7.2 arrives on 8th December, and the interesting part happens first
Sources
- WordPress 7.1.4 Security Release, WordPress.org, 28th October 2026, read 8th November 2026.
- Known Exploited Vulnerabilities catalogue, entry for CVE-2026-119977, added 3rd November 2026, read 8th November 2026.
- CVE-2026-119977 record, assigned by Wordfence, CVSS 8.1 (high), read 9th November 2026.
