CVE-2026-119977 is a race condition in the WordPress core updater. When a site installs a full core update, WordPress unpacks the new files into a predictable folder that the web server will serve. An attacker who lands a request inside that short window can run code on the server, with no account and no user interaction.
It is fixed in WordPress 7.1.4, released on 28 October 2026, with backports going as far down as 4.7.39. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2026 and set a remediation date of 6 November.
WordPress rates this flaw Low. CISA says it is being exploited. Both statements are on the public record, and the gap between them is why a lot of teams have not looked at it yet.
What makes it worth ten minutes is where it sits. Not in a plugin, not in a theme, but in the core update process itself, which is the one job almost every WordPress site runs automatically and unattended.
What CVE-2026-119977 Actually Is
The formal classification is CWE-367, a time-of-check time-of-use race condition. In plain terms, the software checks something, then acts on it, and an attacker changes the facts in between.
During a full-package core update, WordPress downloads the new release and extracts it into wp-content/upgrade/ before moving the files into place. That folder sits inside the web root and the path it uses is predictable. For the few seconds the extracted copy is sitting there, an unauthenticated request can reach a PHP file inside it directly.
Two details make CVE-2026-119977 more awkward than the usual core bug. The attacker needs no account and no help from a logged-in user. And the window is not a one-off: it reopens on every full-package update, including the automatic background updates most sites never think about.
Why WordPress Calls It Low and CISA Calls It Exploited
Four organisations have published a view and they do not agree.
WordPress published its own advisory on 29 October 2026. It rates the issue Low and still records no known CVE against it.
Wordfence is the CVE Numbering Authority here, not WordPress. It assigned CVE-2026-119977 and published it on 31 October 2026 with a CVSS 3.1 base score of 8.1, rated High, on the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
Patchstack landed in between. In its analysis of the 7.1.4 release it agrees the attack complexity is high and says it would not call the flaw practical to exploit, while also noting that it still needs no account and no interaction, and that the window returns on every update.
CISA then added it to the Known Exploited Vulnerabilities catalogue on 3 November 2026, which it does only on evidence of active exploitation.
Read together, the disagreement is narrower than it looks. Everyone accepts the attack is hard to land. What they disagree about is how much that is worth when the window reopens by itself on every site that updates automatically.
Not sure whether your estate is actually patched?
Transputec runs managed IT and cyber security services for UK organisations, including vulnerability management and patching. Talk to our team about the security work behind keeping a web estate current.
Book a consultationWhich Versions Are Affected, and What Fixes Them
CVE-2026-119977 affects WordPress core from 4.7 through 7.1.3. That is close to a decade of releases, so the practical question is not whether a site was ever affected but whether it is current now.
| Affected | WordPress 4.7 through 7.1.3 |
| Fixed in | 7.1.4, released 28 October 2026 |
| Backports | Each older branch was patched too, for example 7.0.8, 6.9.11 and 4.7.39 |
| Added to CISA KEV | 3 November 2026, remediation date 6 November 2026 |
| Ransomware use | Listed by CISA as unknown |
The 7.1.4 release was not a single-issue patch. Patchstack counts 22 vulnerabilities fixed across 17 advisories in that release, so there are reasons to be on it beyond this one.
Why Your Security Plugin Will Not Catch This
This is the detail most summaries leave out, and it is the one worth carrying into a conversation with whoever runs your sites.
A WordPress security plugin is PHP. It runs because WordPress loads it. But the copy of WordPress sitting in the upgrade folder is a fresh, unpacked release that loads from its own files, and the official zip does not ship an mu-plugins directory. So when a request hits a PHP file inside that extracted copy, as Patchstack puts it, the site’s firewall never runs for that request.
In other words, the layer most organisations rely on to buy time between disclosure and patching is the one layer that is structurally absent here. If you were planning to treat a plugin-level rule as your mitigation, it is not one.
Block the Upgrade Folder at the Web Server
Because the protection has to sit in front of PHP, the vendor guidance is to deny web access to the upgrade directory at the web server itself.
On Apache, inside the site configuration:
<Directory "/var/www/html/wp-content/upgrade">
Require all denied
</Directory>On nginx:
location ^~ /wp-content/upgrade/ {
deny all;
}Two things to confirm afterwards. The directory should not be listable, and between updates it should contain nothing but an index.php file. WordPress uses that folder for its own file operations on disk, so denying it over HTTP does not interfere with updates. Test on one site before rolling it across an estate.
This mitigation is worth keeping in place permanently rather than treating it as a response to CVE-2026-119977. It closes the category, not just this instance of it.
What CISA Requires, and Who It Actually Binds
CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalogue on 3 November 2026, with a remediation date of 6 November. The required action points to its BOD 26-04 guidance and to its forensic triage requirements, which is a step beyond simply patching: it asks organisations in scope to go and look for evidence of compromise.
Worth being precise about scope, because this gets overstated. CISA’s binding directives apply to United States federal civilian agencies. If you are a UK business, the deadline is not a legal obligation you are under.
What it is, though, is the clearest public signal available that a flaw has moved from theoretical to used. CISA adds entries to that catalogue on evidence of active exploitation, not on severity scores. When a vendor says Low and CISA says exploited, the catalogue is the one making a claim about the real world.
How to Tell Whether You Were Exposed
Three questions, in order.
Did any site run a full-package core update between 28 October and the day you patched? Partial updates do not use the same path. Full-package updates do, and automatic background updates count.
Was wp-content/upgrade reachable over the web? If a request to that path returned a directory listing or a file rather than a 403, the precondition was there.
Is there anything in that folder now besides index.php? Between updates there should not be.
Be careful about what a clean result proves. Finding nothing unusual is not the same as confirming nothing happened, which is exactly why CISA asked for forensic triage rather than a quick look. If a site handles anything you would not want altered, that review belongs with whoever holds your logs. Our cyber security services cover that kind of work, including vulnerability management and 24/7 monitoring.
The Wider Point About Update Windows
Most vulnerability management assumes the dangerous state is being out of date, and that updating moves you from exposed to safe. CVE-2026-119977 is a reminder that the act of updating is itself a moment of exposure, and on an unattended schedule it is a moment nobody is watching.
That has a few practical consequences worth carrying forward. Know which of your sites update themselves and when. Treat the staging and temporary directories your software writes to as part of the attack surface rather than as plumbing. And when a vendor and a national authority disagree about severity, look at what each is actually measuring. A vendor scores how hard the attack is. CISA records whether anyone is doing it.
We made a related point earlier this autumn about the critical PHP vulnerability known as PHP2Shell, which is a different flaw but the same lesson about how fast a published fix becomes a published roadmap.
The Short Version
Get to WordPress 7.1.4, or the patched release on whichever branch you run. Deny web access to wp-content/upgrade/ at the web server and leave that rule in place. If any site ran a full core update between 28 October and the day you patched, treat it as worth a proper look rather than a glance, because a plugin-level firewall was never in the path to stop it.
And if you are weighing whether this deserves attention at all, the useful test is not the severity label. WordPress scores how hard the attack is. CISA records whether anyone is running it. On CVE-2026-119977 those two are answering different questions, and only one of them is about your site.
Frequently Asked Questions
Is CVE-2026-119977 really being exploited?
CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2026, and it only adds entries on evidence of active exploitation. WordPress itself still rates the issue Low. Several vendors have published counts of blocked attempts, but those figures differ widely between sources and we have not been able to tie them to a single primary advisory, so we are not repeating them here. The KEV listing is the claim worth acting on.
We are already on WordPress 7.1.4. Is that enough?
For the flaw itself, yes. 7.1.4 is the fixed release and it also closes 22 vulnerabilities across 17 advisories, so it is the version to be on. Two things it does not answer. If a site ran a full-package update while still on an affected version, patching afterwards does not undo anything that happened during that window. And the underlying pattern, a web-reachable staging directory, is worth blocking at the web server whatever version you run.
Will a WordPress security plugin block this?
No, and this is the part that catches people out. A security plugin is PHP that runs because WordPress loads it. The copy of WordPress sitting in the upgrade folder loads from its own files and the official release package contains no mu-plugins directory, so the site’s firewall never runs for a request aimed at that extracted copy. Protection has to sit in front of PHP, which means the web server.
Does the CISA deadline apply to UK businesses?
Not as an obligation. CISA’s binding directives apply to United States federal civilian agencies, so a UK business is not legally bound by the 6 November date. It is still the most reliable public indicator available that a vulnerability has moved from theoretical to actively used, and the catalogue entry asks for forensic triage rather than patching alone, which tells you how CISA is reading the risk.
Should we switch off automatic WordPress updates?
No. Automatic updates close far more exposure than they open, and switching them off leaves sites unpatched against everything else, including the other 21 issues fixed in the same release. The right response is to block web access to the upgrade directory so the window is not reachable, and to know which sites update themselves and when. Turning off updates trades a few seconds of risk for weeks of it.
This article was drafted with AI assistance and reviewed by the Transputec team. Featured image: AI-generated.
