Vulnerabilities
WordPress Updater Flaw Listed as Exploited: What the 7.1.4 Security Release Fixes
The flaw sits inside the update mechanism itself, and CISA says attackers are already using it. WordPress shipped the fix on October 28 and backported it to every branch from 4.7 onward.
Photo: Robert Sim, CC BY-SA 4.0, via Wikimedia Commons
WordPress site owners have a short task this week: confirm that every site has taken the 7.1.4 security release, because the most serious flaw it fixes is no longer theoretical. On November 3, 2026, CISA added CVE-2026-119977, a race condition in the WordPress core upgrade process itself, to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation. The federal remediation deadline on the entry was November 6, and the catalog flags forensic triage as required.
WordPress 7.1.4 shipped on October 28, 2026. WordPress describes it as a security release and states that “it is recommended that you update your sites immediately.” The release documentation counts 22 vulnerabilities fixed, with backported releases published the same day for every supported branch from 7.0.8 down to 4.7.39. WordPress 4.6 and earlier receive no fix.
The updater flaw
CISA’s catalog entry describes a time-of-check time-of-use race condition in WordPress Core. During a full package core upgrade, WordPress stages files at predictable, web accessible paths. An unauthenticated attacker who acts inside that short upgrade window can execute code on the server. The CVE record, assigned by Wordfence and published on October 31, credits the discovery to Umut Bayram, the same researcher WordPress thanks in the 7.1.4 notes for reporting the race condition, and scores the flaw 8.1, High. WordPress’s own release page does not publish CVE IDs or severity scores, and site owners should be wary of any summary that attributes numbers to WordPress that it did not issue.
The remaining 21 fixes are mostly stored cross-site scripting issues that require a Contributor account or higher, spread across blocks, the Customizer, and the Interactivity API, plus an information disclosure issue that exposed unpublished Customizer changes to unauthenticated visitors, a permissions issue around comment moderation notes, and hardening fixes. The release also updates the bundled root certificates following the eMudhra revocation, the same trust store change Microsoft applied to Windows in late October.
Photo: Margarit Ralev, via WordPress Bulgaria, CC BY-SA 2.0, via Wikimedia Commons
How to check your sites
Start with the version, not the dashboard banner. A site that reports 7.1.4, or the matching backported release for its branch, such as 7.0.8 or 6.9.11, has the fix. Command line users can confirm with wp core version. Sites with automatic background updates enabled usually took the release on their own, but usually is not verification: hosting dashboards, staging copies, and multisite networks are the places where an update silently fails or is held back.
Because CISA flags forensic triage on this entry, a version check alone is not the whole job for sites that sat unpatched while exposed. Review administrator accounts and scheduled tasks created in late October and early November, look for unfamiliar files under the uploads and upgrade directories, and treat any unexpected admin user as an incident, not a cleanup task. Then close the window that made this flaw dangerous: keep core updates automatic where the site allows it, and shorten the time between a security release and its installation everywhere else.
No corrections have been published for this article.