Yesterday's article looked at Microsoft's analysis of 2,056 exploited CVEs and what real-world exploitation has in common. Twenty-four hours later, the pattern has a live case study.

On November 3, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalog: a high-severity (CVSS 8.1) time-of-check time-of-use (TOCTOU) race condition in WordPress Core. The uncomfortable detail is where the vulnerability lives. The vulnerable moment is the update itself.

The mechanics: a race against your own updater

WordPress Core versions 4.7.0 through 7.1.3 are affected. When WordPress applies a full-package core upgrade, it unpacks the new files into a predictable directory beneath wp-content/upgrade. That staged copy contains the WordPress installer, setup-config.php. On many server configurations the staging directory is reachable over the web. An unauthenticated attacker who requests the staged installer at exactly the right moment can interact with it and progress to PHP code execution on the server.

"Exactly the right moment" is doing a lot of work in that sentence. In Wordfence's lab testing, the staging directory normally existed for only a few seconds. A one-off request is very unlikely to land. But a script that polls the path continuously, for hours, improves its odds considerably, and that is precisely what attackers built.

The vulnerability was responsibly reported by Umut Bayram. WordPress 7.1.4, released on October 28, fixes it by randomizing the staging directory, adding an index guard, and preventing unsafe promotion of staged configuration data. The fix was backported to every supported branch, from 7.1.4 down to 4.7.39. WordPress 4.6 and older no longer receive security fixes at all.

Exploitation started in minutes

The timeline is the story:

  • October 28, 2026 — WordPress 7.1.4 ships as a security release covering 22 vulnerabilities.
  • 20:30 UTC the same day — Wordfence deploys a blocking firewall rule, roughly three hours after the release announcement.
  • Nine minutes later — the first request matching the new rule arrives.
  • First 21 hours after public disclosure — Wordfence records more than 18,500 requests targeting staged setup-config.php installer paths. Two of the largest sources repeatedly polled small groups of sites for about 14.5 hours, behavior consistent with trying to catch the brief upgrade window. Other sources tested staging-directory and version-name variations, showing the attackers understood the race condition quickly.
  • October 30 — telemetry from Previdian records three exploitation attempts against its honeypot sensors from an IP address geolocated in the U.K.
  • November 3 — CISA adds the CVE to the KEV catalog, citing evidence of active exploitation, and gives U.S. federal civilian agencies until November 6 to apply the fixes. Known ransomware campaign use: unknown. As of November 4, Wordfence was still blocking over 12,600 exploit attempts per day.

The chicken-and-egg problem, stated honestly

There is an awkward truth in this vulnerability: patching is exactly when the window opens. If an attacker is polling your site for the staging path, the moment you click "Update Now" is the moment they have been waiting for.

A reader raised this in the comments on the Wordfence disclosure, and the exchange is worth reading because both sides are right. The technically precise move, if you manage your own server or CDN layer, is to temporarily deny web access to /wp-content/upgrade/ for the duration of the update, at the server, firewall, or DNS level, and then update. But the Wordfence response is the operationally honest one: most of the millions of WordPress site owners cannot do that quickly, and delaying the update while they figure out how leaves them exposed to all 22 vulnerabilities for longer. The race window is seconds; the exploitation attempts observed so far were concentrated, not universal. For the overwhelming majority of sites, updating immediately is still the right call.

That nuance matters more than the usual "patch now" headline. The correct advice is not "update" or "wait." It is: update now, and if you have the access and the skill to shield the staging path during those seconds, do that first.

What to check today

  1. Verify the version, do not assume it. Automatic background updates cover most sites, but they fail silently more often than people think. Dashboard → Updates should show 7.1.4 or the patched point release for your branch. If the site still runs 4.6 or older, it is outside security support entirely and needs a real upgrade, not a patch.
  2. If the site stayed unpatched after October 28, look backwards. Suspicious signs: requests to PHP files beneath wp-content/upgrade in access logs, unfamiliar administrator accounts, plugins nobody installed, PHP files nobody placed.
  3. A firewall rule is not the patch. This exploit requests a staged PHP file directly, without loading WordPress first, so plugin-level defenses only work if they run before the request reaches the file (Wordfence calls this Extended Protection). Whatever WAF you use, the rule buys time. Only the update removes the vulnerable behavior.
  4. Treat the KEV deadline as a floor, not a target. November 6 binds U.S. federal agencies. If the site matters to you, the fact that probing began nine minutes after a defensive rule deployed tells you the timeline you are actually on.

The pattern, again

An update mechanism is a privileged process that everyone trusts by design, running with write access to the application itself. The WordPress installer had to be staged somewhere for the update flow to work, and "temporary" plus "predictable" plus "web-accessible" turned out to be the whole vulnerability. It extends yesterday's theme uncomfortably well: the processes we trust most blindly deserve the most scrutiny, and few things are trusted more blindly than an updater.

The update button is part of the attack surface. This week, so are the few seconds after you press it.

Sources: WordPress 7.1.4 release note, Wordfence disclosure and telemetry, Wordfence threat intel entry for CVE-2026-119977, CISA Known Exploited Vulnerabilities catalog, The Hacker News.