WordPress 7.1.4 released October 28, 2026; CISA KEV addition November 3, 2026; federal remediation due November 6, 2026
Deadline Day for the WordPress Updater Race: Patching CVE-2026-119977 Is Only Half the Job
The federal deadline for CVE-2026-119977 lands today. The flaw is a time-of-check time-of-use race in WordPress core updates: during a full-package upgrade, versions 4.7 through 7.1.3 unpack the new release into a predictable, web-accessible staging directory under wp-content/upgrade, and an unauthenticated attacker who reaches the staged installer files in the seconds before cleanup can execute code on the server. WordPress fixed it in 7.1.4 on October 28, with backports for every branch back to 4.7.39, by randomizing the staging directory and guarding the staged files. The severity record needs both numbers stated: Wordfence, the CVE numbering authority that assigned the CVE, scores it 8.1 with high attack complexity, while WordPress itself rates the issue Low, and both describe the same facts. CISA added the flaw to the Known Exploited Vulnerabilities catalog on November 3, based on evidence of active exploitation, with remediation due today, November 6, under BOD 26-04, and the required action includes forensic triage, not only patching. Wordfence recorded more than 18,500 requests targeting staged setup-config.php installer paths in the first 21 hours after disclosure, with some sources polling small groups of sites for roughly 14.5 hours to catch the brief window. Those requests go directly to PHP files and do not load WordPress, so controls that only inspect WordPress traffic can miss them. Neither CISA nor Wordfence has published details of a confirmed site takeover, and no actor has been attributed.
Executives
Treat today as two deadlines, not one. The patch deadline is the visible half; the other half is proof that no site was compromised during an earlier update window. WordPress runs marketing sites, portals, and documentation properties that often sit outside central IT ownership, including sites run by agencies and hosts. Ask for the full inventory of WordPress properties with a named owner for each, and for each site either fixed-version evidence plus a log review, or an explicit statement that the logs no longer exist. An assurance gap recorded honestly is worth more than a clean report nobody can support.
CIO / CISO
Close this in two tracks. Track one is version: every instance on 7.1.4 or its branch backport, with sites on 4.6 or earlier moved to a supported release, since no fix exists for them. Track two is triage, as CISA's required action demands: review web logs around every core update since late October for requests to PHP files under wp-content/upgrade, and check for unexplained administrator accounts, unexpected plugins, and altered core files. Deny web access to wp-content/upgrade at the server level as a standing control, and require controlled updates, with the staging path restricted before the update starts, for high-value sites.
Engineers
Verify the running version per site rather than trusting an update notice, and keep the evidence with the ticket. The request pattern to hunt is direct requests for setup-config.php or other PHP files beneath wp-content/upgrade, especially repeated polling of the same site, because those requests bypass WordPress and its plugin firewalls; server and edge logs are the record that matters. Note that Wordfence free users do not receive its firewall rule until November 27, so the server-level deny rule and the version check carry the weight this week.
Everyone (non-IT)
If you run a WordPress site for a club, a small business, or yourself, check today that it is on version 7.1.4 or the fixed release for your branch, in Dashboard, Updates. Most sites update themselves, but checking takes a minute and assuming is how sites stay exposed. If your site is run by someone else, ask them the same question and ask whether they reviewed the site for changes nobody made.