CISA Confirms Active Exploitation of a WordPress Core Race-Condition Flaw
CISA has added CVE-2026-119977, a time-of-check to time-of-use race condition in WordPress Core that allows unauthenticated code execution during upgrades, to its Known Exploited Vulnerabilities catalog, with federal agencies given until November 6, 2026 to patch.
CISA has added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog, citing evidence of active exploitation of a flaw in WordPress Core. The listing starts a clock rather than merely issuing a warning: federal civilian agencies were ordered to secure affected systems by November 6, 2026 under Binding Operational Directive 26-04.
The vulnerability is a time-of-check to time-of-use race condition in WordPress Core that allows unauthenticated attackers to execute code on a server during an upgrade window. That class of bug is worth understanding on its own terms. The code checks a condition — a file’s permissions, a path’s ownership — and then acts on it, and if the underlying state changes in the gap between those two moments, the check has validated something that no longer exists by the time the action runs. Ordinarily that gap is microseconds wide and nothing interesting happens inside it. An upgrade is the one moment when the filesystem is being rewritten underneath the running application, which is precisely the window an attacker needs.
The flaw was reported by Picus Security researcher Umut Bayram, and WordPress 7.1.4, released on October 28, 2026, patches it. Two days later, on October 30, Previdian recorded exploitation attempts originating from a UK IP address — a short gap between a fix shipping and someone trying the door anyway.
The volume is the more striking number. Wordfence blocked 12,632 attacks targeting the vulnerability in a 24-hour period, per The Hacker News’ account of the KEV listing; Bleeping Computer’s figure for the same window was 13,095. The two counts differ slightly, which is unremarkable for two vendors measuring their own sensor networks, but both describe the same thing: automated, sustained attempts at a scale that implies tooling rather than curiosity.
What makes this one awkward is that the vulnerable moment is a routine administrative operation. Upgrades are supposed to be the safe thing you do — the maintenance task that closes holes rather than opening them — and a race condition living inside that task inverts the usual advice. The mitigation is the patch, and the patch is out. The problem is the population of sites that upgrade on their own schedule, or not at all, and the fact that exploitation requires no credentials means there is no login to watch for.
For federal agencies the deadline is November 6, 2026, and the KEV listing makes compliance auditable in a way a vendor advisory never does. For everyone else running WordPress, the calendar is less formal but the arithmetic is the same: the flaw is public, the exploitation is confirmed, and the only thing standing between a site and a bad afternoon is whether 7.1.4 has actually been installed.