WordPress core race condition lands in CISA KEV, and a patch is out
CISA added CVE-2026-119977 to KEV. The WordPress flaw allows unauthenticated code execution during core updates. Fixes shipped October 28 for every branch back to 4.7. Update now and check your logs.
Translated from the German original with an AI language model, approved by me. Read the original
On November 3, 2026, the US cybersecurity agency CISA added the WordPress core flaw CVE-2026-119977 to its KEV catalog. KEV stands for "Known Exploited Vulnerabilities." CISA only lists a flaw there when it has evidence that attackers are actively exploiting it. Earlier reports covered only exploitation attempts. Now the flaw is officially classed as exploited.
One correction to my post on X and in the WhatsApp channel: there I listed the patch status as unclear. In fact, a fix has been out since October 28.
What happened
The flaw is a TOCTOU race condition. TOCTOU stands for "time of check to time of use": a system checks something, then acts on the result a moment later. Whoever moves faster in that short gap can step in.
In WordPress, this affects core updates that use the full update package. According to WordPress advisory GHSA-4w3m-c66w-69mg, affected versions unpacked the new files into a predictable directory inside the web-served upgrade folder. An attacker who wins the race against that extraction can run PHP code on the server without logging in. No account and no admin action is needed.
How serious is it?
Not everyone agrees on the rating. WordPress itself rates the flaw "Low." The CVE record scores it CVSS 8.1, which is "High," according to Ostorlab and runZero. CVSS is the standard severity scale from 0 to 10. The gap comes down to the time window: it lasts only seconds, so an attack is hard to pull off. The high score already counts that as "high attack complexity."
On the activity so far: Ostorlab reports that Wordfence blocked almost 63,000 requests aimed at the flaw in the 24 hours up to October 30. Those were attempts, not confirmed break-ins. CISA's KEV notice gives no details on successful attacks, but the listing is based on "evidence of active exploitation." How many sites were actually compromised has not been made public.
My take: "hard to exploit" is no excuse to wait. These attacks are automated and run at huge scale, and WordPress is on a vast number of servers. Try often enough and you'll win a race eventually.
Who is affected
Per the advisory, every WordPress version from 4.7.0 through 7.1.3 is affected. The fix is in 7.1.4, with backports to every older branch back to 4.7, for example 7.0.8, 6.9.11, 6.8.12 and 4.7.39. The full list is in the advisory. Pantheon describes 7.1.4 as a security release that fixes 13 issues in total, including several stored XSS bugs.
There is one important condition. According to Ostorlab, the flaw can only be exploited if the staging directory under wp-content/upgrade/ is reachable from the web and PHP files in it can run. That's true on many standard hosting setups.
What you should do now
- Update. Take a backup, then install 7.1.4 or the patched release for your branch. The advisory names this as the fix.
- Know the auto-update catch. Background auto-updates will deliver the fix. But the update itself still runs on the old, vulnerable code. As Ostorlab explains, that means the one update window is still exposed.
- Block the upgrade folder if you can't update right away. Deny web access to
/wp-content/upgrade/at the web server, for example with a 403 rule. This covers only this flaw and doesn't replace the update. It's best to put the block in place before you update, so the update window is covered too. - Check your logs and the directory. Search your web server logs for requests to PHP files under that path. Look in the directory for PHP files that don't belong there. A single hit is a lead worth following up, not proof of a break-in.
- Clean up. After the update, delete any leftover files in the upgrade folder.
If you run lots of sites, as agencies and hosts do, set the block centrally at the server level. That's faster than touching every install one by one.