Updating WordPress Is the Risky Moment: CVE-2026-119977 Is on CISA's Exploited List, and the Update Itself Opens the Window
If you run WordPress, block web access to the folder wp-content/upgrade on your web server before you click Update, then update to 7.1.4 (or the fixed release for your branch). CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on Tuesday, November 3, 2026, with a federal due date of Friday, November 6. That is a three-day deadline.
What the flaw is
WordPress's own security team describes it as "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window." It was reported by Umut Bayram of Picus Security.
Picus's write-up explains the mechanism. When a core update runs, WordPress unpacks the new files into a staging folder under wp-content/upgrade. That staging copy includes the WordPress installer. In certain update types the installer can be pointed at the live site's wp-config.php while the update is running. An attacker who wins that race can create the first administrator account against an empty database and then upload a plugin to run PHP. On the older releases the staging folder name is easy to predict, and the fix makes it unpredictable.
This is a race. It only exists during the update, and BleepingComputer describes the attack as high complexity. That is why the first thing to do is close the folder to the web, not rush the update.
What is confirmed and what is not
- Fixed in WordPress 7.1.4, released October 28, 2026. The release notice says fixes were backported to "all branches eligible to receive security fixes (currently through 4.7)" and that "the backports are in progress and will ship as they become ready." So check that your branch has actually received its release.
- The WordPress notice names no affected versions and gives no severity. Wordfence's record says WordPress Core 4.7 through 7.1.3. Picus says the underlying updater behavior goes back to 2.7.0, and that 2.7 through 4.6 get no fix at all. Those two ranges come from different vendors, so we are not choosing between them: anything below 4.7 is unsupported and should be moved to a supported release.
- Severity is disputed. One report has Wordfence at CVSS 8.1 (high) and the WordPress project rating the same race as low. We have not read either rating at its source.
- CISA says it is exploited and gave no further detail. Wordfence said it blocked 13,095 attacks targeting this in a 24-hour period. That is attempts blocked on sites Wordfence protects, not successful compromises, and not a count of all sites.
- The WordPress notice offers no workaround. The folder block below is Picus's guidance, not WordPress's.
What to do, in order
- Block web access to wp-content/upgrade. In nginx, a location block for ^~ /wp-content/upgrade/ with deny all. In Apache, deny access to that directory in the virtual host. If you only have .htaccess, add a 403 redirect for ^/wp-content/upgrade/ in the root .htaccess above the WordPress rewrite rules. Do not put a .htaccess file inside the upgrade folder itself, because the unpatched updater clears that folder before it unpacks.
- Confirm that a request to /wp-content/upgrade/ now returns 403.
- Update to 7.1.4 or your branch's fixed release. Picus notes that clicking Update Now from an unpatched site still leaves one last window open, which is why step 1 comes first. WP-CLI's core update uses the same updater.
- If you manage many sites, or do not want the live updater involved, Picus describes updating from outside the web root by copying the new core directories over and leaving wp-content and wp-config.php alone.
- Afterwards, check for administrator accounts you did not create, plugins you did not install, a site showing the WordPress setup screen, and a wp-config.php sitting inside a wp-content/upgrade subfolder. These are signs we derived from the mechanism. No vendor has published indicators of compromise, and we are not publishing addresses or hashes because none exist in the sources we read.
What our edge saw
We checked our own edge instruments for this pattern since October 28. These are our observations of scanning, not evidence of exploitation of this bug.
- Edge blocks: 24,526 blocked requests scanned, none to wp-content/upgrade or setup-config.
- Edge canaries: 11 hits from 7 addresses on /wp-admin/setup-config.php between October 29 and November 9. That path is the standard WordPress installer and is probed all the time, so it does not show anyone attacking this CVE.
- Origin honeypot: one request to /wp-content/upgrade/index.php on November 1, out of 349 captured. One request cannot tell us whether it was targeting this bug.
We have no proof-of-concept timeline to compare against, so we make no claim about being early or late.
Sources
CISA Known Exploited Vulnerabilities catalog (dateAdded 2026-11-03, dueDate 2026-11-06). WordPress 7.1.4 release notice, October 28, 2026. BleepingComputer, November 4, 2026. Picus Security, "CVE-2026-119977: When Updating WordPress Becomes the Vulnerability."
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.