On this page
CISA added the WordPress update bug, CVE-2026-119977, to its list of vulnerabilities attackers are known to exploit on Tuesday, Nov 3. If a WordPress site ran a core update while its upgrade folder was reachable from the web, someone could hijack that update and end up running their own code on the server. Updating now closes the hole. It does not tell you whether someone got in during an earlier update, and CISA's listing asks agencies to check that too.
We covered the bug itself when WordPress 7.1.4 shipped on Oct 28, in our write-up of the 7.1.4 security release. It had no CVE ID then. This post covers what changed: the CVE, the catalog listing, and the question it raises for every site that updated in the last week.
What changed today
- CISA KEV listing, Nov 3. The catalog entry names WordPress Core, calls it a time-of-check time-of-use race (CWE-367), and gives federal agencies until Nov 6 to act. That is three days, shorter than the usual window. The entry is marked for forensic triage, and ransomware use is listed as unknown.
- The CVE ID. Wordfence, acting as the CVE Numbering Authority, published CVE-2026-119977 on Oct 31 with CVSS 3.1 8.1 (AV:N/AC:H/PR:N/UI:N). NVD has marked the record Deferred and has not scored it.
- The severity gap. WordPress's own advisory, GHSA-4w3m-c66w-69mg, still rates it Low. Wordfence rates it High. CISA has now said it is being exploited, which settles which number to plan around.
CISA does not publish the evidence behind a listing. Wordfence reported more than 18,500 requests for staged installer paths in the first 21 hours after its firewall rule shipped, with some sources polling the same small groups of sites for about 14.5 hours. When we checked on Nov 3, neither CISA, WordPress nor Wordfence had described a specific site that was taken over.
How to fix
Update WordPress, and confirm it took:
wp core update
wp core version # 7.1.4, or the fixed release for your branch
wp core verify-checksumsFixed releases exist for every branch from 4.7 up: 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, then 6.5.14 down to 4.7.39. NVD's affected list ends at 4.7.38 on the oldest branch.
Then deny web access to the upgrade folder at the web server, so the next update cannot be raced either:
# nginx, inside the server block
location ^~ /wp-content/upgrade/ { deny all; }
# Apache, vhost or root .htaccess, outside the # BEGIN WordPress block
RedirectMatch 403 ^/wp-content/upgrade/Put the rule in server config, not in a PHP security plugin. The staged copy of WordPress boots from its own files, so your plugins never load for these requests.
Find out whether your last update was raced
Patching answers whether the next update is safe. The KEV listing makes the earlier updates the open question, and the one most worth checking is the update to 7.1.4 itself: it was unpacked by the old, unfixed upgrader, on a day when attackers were already polling for the folder.
Start with when the core update ran. The core version file is rewritten on every core update:
stat -c '%y %n' wp-includes/version.phpThen look for successful requests into the upgrade folder that ask for the installer. Run this in your web server's log folder. Normal traffic has no reason to request either file:
grep -h 'wp-content/upgrade/' access.log* | grep -E 'setup-config|install' | grep '" 200 'Any 200 near the time from stat is the case to chase. Requests that got 403 or 404 are the probing Wordfence describes, not a takeover. If your logs do not reach back to Oct 28, check the site itself:
grep -E "DB_HOST|DB_NAME|DB_USER" wp-config.php # must point at your own database
stat -c '%y %n' wp-config.php # changed when you did not change it?
wp user list --role=administrator --fields=user_login,user_registered
find wp-content/upgrade -type f ! -name index.php -lsA wp-config.php pointing at a database host you do not recognize means the update carried an attacker's config into the live site. Treat that site as compromised: take it offline, restore from a backup taken before the update, and rotate the database password and all admin passwords.
Who is not in scope
- Sites deployed by Composer, git or container images with
DISALLOW_FILE_MODSset to true. They never run the built-in core updater, so there is no window to race. They still need the fixed code. - Servers that already denied web access to
wp-content/upgrade/before their last update. The race needs that folder reachable over HTTP. - WordPress older than 4.7. The CVE record's affected range starts at 4.7.0.
What this is not
This is not a bug an attacker can fire at any WordPress site at any time: the site has to be in the middle of a full core update, for a few seconds, with the upgrade folder served over the web. A KEV listing means CISA has evidence of exploitation somewhere. It does not mean every site that ran the old upgrader was hit, which is why the log check above is worth ten minutes.
The HOL Guard CVE-2026-119977 evidence pack keeps the source records for this issue.
What do people ask about CVE-2026-119977?
Is CVE-2026-119977 being exploited?
CISA added it to its Known Exploited Vulnerabilities catalog on Nov 3, 2026, which means CISA has evidence of exploitation. Wordfence logged more than 18,500 attempts to reach the vulnerable path in the first 21 hours after its firewall rule shipped. No public report has described a specific site that was taken over.
Which WordPress versions fix CVE-2026-119977?
WordPress 7.1.4, plus backports for every branch back to 4.7, including 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11 and 4.7.39. Versions 4.7.0 through 7.1.3 are affected.
Is my site safe if automatic updates installed 7.1.4?
Future updates are protected. The update that installed 7.1.4 still ran the old upgrader, so check your access logs for successful requests to setup-config.php or install.php under wp-content/upgrade around that time.
What is the CISA deadline for CVE-2026-119977?
Federal civilian agencies have until Nov 6, 2026. The entry is also marked for forensic triage, so agencies are expected to look for signs of compromise, not just patch.
