WordPress update flaw hits CISA's list: 25 fixed builds, due Nov. 6

CISA added CVE-2026-119977, a race condition in WordPress core, to its Known Exploited Vulnerabilities catalog on November 3, citing evidence of active exploitation. The due date for federal civilian agencies is November 6, three days after listing, and the entry is marked for forensic triage under CISA's directive BOD 26-04. That directive binds only federal civilian agencies, but CISA urges all organizations to prioritize KEV entries. WordPress fixed the flaw in 7.1.4 on October 28 and in back-ported releases for every branch down to 4.7.

The flaw is in the update process itself. During a full-package core update, WordPress unpacked the new files into a predictable folder under wp-content/upgrade/, and that folder could be reached from the web. The staged copy includes the installer, wp-admin/setup-config.php. WordPress's advisory says an unauthenticated attacker who beats the extraction in a race could achieve remote code execution. Wordfence says that means requesting the staged installer in the seconds the copy exists. The fix randomizes the staging folder name and adds an index guard, Wordfence says; Patchstack found that 7.1.4 appends 16 random characters to the name.

That may make it an odd patch for IT teams. Rescana, a third-party risk management firm, says that in its reading the old code, with the flaw still in it, unpacks the 7.1.4 update. Separately, Alex Thomas, who wrote Wordfence's post, agreed with a reader in the comments that blocking the folder before updating is the best course for those who can, though he said the flaw is very hard to exploit and most site owners should update right away. WordPress has not addressed the point.

How serious is it?

The two scores disagree. WordPress rates the flaw "Low" in its GitHub advisory. Wordfence, which assigned the CVE, scores it 8.1 (High) and says that reflects the result of a successful attack; the attack complexity is high. In Wordfence's tests the folder was usually open for only seconds, though repeated automated polling improves an attacker's odds. Patchstack does not consider it practical to exploit. NVD has not scored it yet.

Attackers are trying anyway. Wordfence put a firewall rule live for paying customers on October 28 at 20:30 UTC, about three hours after the release post, and its first match arrived nine minutes after that. Over the first 21 hours it logged more than 18,500 requests aimed at staged setup-config.php paths, though not all used the exact vulnerable path. Two of the biggest sources hit small sets of sites repeatedly for about 14.5 hours. The Hacker News reported that Wordfence had blocked 62,969 attacks in 24 hours. When we checked Wordfence's page early on November 4 (UTC), its rolling counter showed 12,478 in the past 24 hours. No source we read reports a confirmed compromise, and CISA has not said what its evidence is.

Which versions are affected and fixed

Versions 4.7.0 through 7.1.3 are affected. WordPress released a fixed build for each of 25 branches:

WordPress 4.6 and earlier get no fix. WordPress also says only the newest version is actively supported, so back-ported builds are a stopgap. The 7.1.4 release fixes 22 vulnerabilities in all, by WordPress's count. webhosting.today, reading WordPress.org's statistics, puts 64.4% of installs on the 7.1 branch, with 34.6% on branches 4.7 to 7.0 and 0.95% on versions older than 4.7.

Why auto-updates may not have covered you

Existing installs take minor core updates by default, and WordPress's release post says sites with automatic updates will update on their own. Fleets can switch that off. The AUTOMATIC_UPDATER_DISABLED constant, WP_AUTO_UPDATE_CORE set to false and the allow_minor_auto_core_updates filter all stop it, and WordPress skips automatic updates when it detects a version-control checkout. Sites run from a Git or other version-control checkout will not pick up 7.1.4 on their own, and neither will sites whose deployment pipeline turns auto-updates off. Wordfence's advice is to check each site rather than assume the update ran.

Plugin firewalls are a weaker backstop than usual. The attack requests a staged PHP file directly, without loading WordPress, Wordfence says, so its rule needs the "Extended Protection" setting to see it. Wordfence Free users get the rule on November 27, 21 days after CISA's due date. Patchstack says flatly that "a PHP firewall cannot block it."

Related: PHP2Shell: the patch paths by distro and Magento PolyShell on CISA's list.