Vulnerabilities
The WordPress flaw that only fires during an update
CVE-2026-119977 lets an unauthenticated attacker run code on a WordPress site, but only while core is updating. Confirm you are on 7.1.4 now.
On November 3, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalog, the list of flaws it has seen used in real attacks. Federal civilian agencies had until November 6 to fix it. The bug is in WordPress core itself, not a plugin or theme, and it affects every release from 4.7 through 7.1.3. The fix shipped in WordPress 7.1.4 on October 28. Exploitation is still going on.
What makes this one unusual is when it can be used. An attacker cannot reach it against a site sitting still. The hole is only open for the few seconds each time WordPress installs a full core update, which is also the moment most site owners think they are getting safer. If you run WordPress anywhere, the question is not only "am I patched" but "was I exposed during my last automatic update".
How it works
The flaw is a race condition, which the CVE record classifies as CWE-367, a time-of-check to time-of-use (TOCTOU) problem. That label describes a gap between the moment code checks a file and the moment it uses it. If an attacker can change the situation inside that gap, the check no longer describes what actually happens next.
During a full-package core update, WordPress downloads the new version, unpacks it into a temporary working directory, and runs an installer step before it moves the files into place and deletes the temporary copies. For the short time those files sit on disk, they include PHP scripts that were meant to run only once, internally, as part of finishing the update. The vulnerability is that an unauthenticated request arriving in that window can cause one of those scripts to execute, which gives the attacker PHP code running on your server with no login.
Several conditions have to line up at the same instant for an attack to land, which is why it is awkward to exploit rather than trivial. It needs a full-package update that includes the installer files, not a small incremental one. The temporary directory has to be reachable over the web with PHP turned on, so the attacker's request can actually run the file. The path has to be guessable or discoverable. And the attacker has to arrive before WordPress finishes and deletes the files. Miss the window and there is nothing to hit until the next update.
The update is the attack window
A typical vulnerability stays reachable until you patch it. This one is reachable only during the update that installs a new version, and only on releases before 7.1.4. A site that never updates core is not exposed through this bug, and a site already on 7.1.4 is not exposed either. The risk sits on everything in between: every WordPress install from 4.7 to 7.1.3 that still runs core updates.
Automatic background updates, which most WordPress sites have on by default, do not remove this risk on their own. Until an install reaches 7.1.4, each time it pulls a core update it opens the same brief window, so a site on auto-update is repeatedly exposed for a few seconds at a time rather than protected. The way out is to land on 7.1.4 (or the patched release for your branch), after which the update process no longer leaves an exploitable file behind.
What attackers are doing
The security vendor Wordfence, which runs a firewall in front of large numbers of WordPress sites, reported blocking high volumes of requests aimed at this flaw. The figures move around and are worth reading carefully, because they count requests the firewall stopped, not sites that were taken over. Daily snapshots ran from roughly 13,000 blocked attempts in a 24 hour period to a peak of more than 74,000 on October 30, and the running total passed 240,000 blocked attempts by November 6. Those are attempts against Wordfence-protected sites only, so the real internet-wide volume is higher.
No successful compromise has been confirmed in public, and no indicators of compromise, such as attacker IP addresses or file hashes, have been published. That absence is not proof that no site was hit. It means nobody has reported one, and without published indicators you cannot grep your logs for a known-bad signature yet.
Severity is disputed, and the gap is wide. The WordPress project's own advisory rates the issue "Low". The CVE record and Wordfence score it 8.1 on the Common Vulnerability Scoring System (CVSS), a 0 to 10 scale where 8.1 is "High". The difference comes from how each side weighs the conditions above: WordPress treats the narrow timing window as a strong barrier, while the CVE scoring treats unauthenticated remote code execution as serious whatever the odds. CISA's decision to add it to KEV, and the live attack traffic, mean you should act on the high end of that range.
What to do
Confirm the version first. On a single site, the admin dashboard footer and the Updates page both show the core version; you want 7.1.4 or the patched release for your branch. From the command line, WP-CLI (the official WordPress command-line tool) reports it with wp core version, and wp core update applies the fix. Anything below 7.1.4 on the 7.1 line, or the equivalent for an older branch, is still vulnerable.
For managed estates and WordPress Multisite, where one codebase can serve many sites, the real work is inventory. List every install and its version before you start patching, because the exposure is per codebase and a single forgotten staging copy keeps the window open. A loop over wp core version across your hosts gives you that list quickly.
Close the exposure the flaw depends on. The temporary upgrade directory should not be reachable over the web with PHP enabled. Confirm that requests to wp-content/upgrade and the upgrade temp paths are blocked at the web server, and tighten file permissions so the web user cannot execute files written there during an update. These steps shrink the attack even on an install you have not patched yet.
Watch the update itself. While core updates run, look for unexpected PHP files appearing under wp-content/upgrade or similar temporary locations, and for requests to those paths in your access logs that do not come from the update process. A file or a request that lands in that directory from outside, during an update you did not trigger, is worth investigating.
If you are not sure what WordPress you expose or how many copies are out there, our attack surface management work builds and keeps that inventory, and our safeguarding and hardening team can lock down the upgrade paths and file permissions so the window closes for good. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: CISA KEV catalog, BleepingComputer, WordPress 7.1.4 release, Patchstack, Security Affairs.