On 3 November 2026 CISA added CVE-2026-119977, a race condition in the WordPress core updater, to its Known Exploited Vulnerabilities catalog. An attacker who wins the race during a full core update could run code on the server. Versions 4.7 through 7.1.3 are affected, and fixes are 7.1.4 and backported releases.
What happened
- 28 October 2026, the fix. WordPress released version 7.1.4 and described a weakness in the upgrade process that can lead to remote code execution during the upgrade window. It credited Umut Bayram with the report. The release also fixes other issues, including stored cross-site scripting.
- 29 October, the advisory. The WordPress security advisory GHSA-4w3m-c66w-69mg lists fixes for every branch still eligible for security fixes, from 7.1.4, 7.0.8 and 6.9.11 down to 4.7.39. It rates the flaw Low.
- 31 October, the CVE. The CVE record, published with Wordfence as the source, scores it 8.1 (High) under CVSS 3.1. ThreatDefence puts the gap between the two ratings down to attack complexity, not impact, and Patchstack says it would not call the flaw practical to exploit.
- 3 November, the CISA listing. CISA added the flaw on evidence of active exploitation. The catalog sets a 6 November deadline for US federal civilian agencies. That date does not bind private companies, but it shows how urgent CISA considers the flaw.
What is known about the attacks. During a full-package core update, WordPress unpacks files into a staging folder that can be reached from the web. The Hacker News, citing Wordfence, reports more than 18,500 requests against staged setup-config.php installer paths in the first 21 hours after public disclosure, and Security Affairs says these figures document attempts, not confirmed compromises. The Hacker News also reports that Previdian recorded three attempts against its honeypot sensors on 30 October. None of the reports we read names a confirmed victim, and ThreatDefence and Safeguard say no attacker indicators have been published.
What it means for businesses
Three points matter beyond WordPress itself.
The risk is in the update. The flaw exists only during the seconds of an update, so a site is not exposed all day. Safeguard reads the code as meaning that the first update to the fixed release is still unpacked by the old updater, so that one update passes through the same window. It labels this its own reading, not a statement from WordPress.
A vendor severity rating is not a priority. The same flaw is rated Low by its project and High by the CVE record, and it is now on CISA's exploited list. Evidence of exploitation should move a flaw up your queue, whatever its label says.
Automatic updates need checking. They help, but they do not prove that every site is patched. Forgotten staging sites, old microsites and installs with updates turned off are where this kind of flaw tends to stay open. Sites on 4.6 or earlier receive no fix. The CVE record does not list them as affected, but WordPress.org marks them insecure.
What to do next
- List every WordPress install you own or pay for, including staging copies, campaign microsites and anything run by an agency or a former supplier.
- Confirm each version. Each site should be on 7.1.4 or the fixed release for its branch. Check the installed version rather than assuming an automatic update has finished.
- Consider blocking web access to /wp-content/upgrade/ before you update. ThreatDefence, Safeguard and Patchstack all advise this. Safeguard labels it its own suggestion, and the WordPress advisory gives no such workaround. Test the rule on a staging copy first.
- Do not treat the rule as a substitute for the update. WordPress says to update immediately, and ThreatDefence says a firewall rule does not replace the update.
- Check for signs of an attack. Vendors suggest looking in web logs for requests under wp-content/upgrade, especially to staged setup-config.php or install.php files. Also look for unexpected PHP files in uploads, upgrade or mu-plugins, new administrator accounts and changes to wp-config.php. These are vendor checks, not an official list.
- If something looks wrong, keep the evidence. Save logs and a copy of the site before you clean it. Then rotate database passwords, salts and administrator credentials, and bring in incident response help.
- Plan for sites on 4.6 or earlier. With no security fix available, the realistic options are to upgrade, rebuild or retire them.
- Name an owner for patching. Decide who watches security releases, how quickly they must act and who checks the result. Our guide to what software maintenance covers explains what that work involves.
Timeline Digital, a custom software development company founded in 2013 in Islamabad, builds and maintains websites and custom software as managed projects, including website design and development and software maintenance and support under a service level agreement. Every project starts with a free pilot: Before you commit to the full project, we build 2 to 3 of your key modules as working software, free of charge, ready in about 2 days. Your team tests the pilot, and the full build starts only after you approve it.
Sources
- WordPress 7.1.4, WordPress.org, 28 October 2026
- A race condition during core updates that could lead to remote code execution, WordPress on GitHub, 29 October 2026
- CISA Adds One Known Exploited Vulnerability to Catalog, CISA, 3 November 2026
- U.S. CISA adds WordPress flaw to its Known Exploited Vulnerabilities catalog, Security Affairs, 4 November 2026
- CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades, The Hacker News, 4 November 2026
- WordPress 7.1.4 Upgrade-Window RCE (CVE-2026-119977): Hunting Exploitation, Checking Sites and Patching, ThreatDefence, published 31 October 2026, updated 4 November 2026
- WordPress CVE-2026-119977 on KEV: Find Every Install, Patch to 7.1.4, Safeguard, 4 November 2026
- WordPress 7.1.4 Security Release, Patchstack, 28 October 2026