Home / Blog / WordPress Vulnerability CVE-2026-119977: Patched, Then Exposed

WordPress Vulnerability CVE-2026-119977: Patched, Then Exposed

There is a special kind of irony reserved for security teams: the update that closes a hole arrives with the hole still open. WordPress 7.1.4 shipped last week to fix CVE-2026-119977, an actively exploited flaw in the core updater — and, as Picus Security researcher Umut Bayram documented, the update that installs the fix still unpacks its files using the old, unpatched code. For a few seconds the vulnerable installer is reachable one final time. Wordfence logged attack attempts nine minutes after publishing its firewall rule, with two of the busiest sources probing small groups of sites for roughly 14.5 hours. That is not noise. That is a schedule.

A TOCTOU window inside wp-content/upgrade

When WordPress applies a complete package, it unpacks a full copy of the new release — installer included — into a temporary directory under wp-content/upgrade. That directory lives inside the web root, so the installer answers over HTTP. The fix in 7.1.4 randomises the folder name, but the updater performing the installation is still the old one: on 5.9 and later it derives the name from the downloaded archive, which makes it predictable exactly once. An unauthenticated attacker who guesses it can drive the installer, point the temporary copy at their own database, log in, and execute PHP with the web server's privileges before the directory is deleted. From there it is a short hop to reading and writing files in the live site.

WordPress rated the flaw low; the CVE record scores it 8.1, and CISA added it to the KEV catalog on evidence of active exploitation. Bayram's lab tests put the window at seconds. Seconds is plenty when the scanner never sleeps.

Pixel art of WordPress wp-content/upgrade folder exposing the installer during the CVE-2026-119977 update window
The updater unpacks a web-reachable installer one last time.

Why botnet herders collect WordPress shells

A compromised WordPress install is not a trophy, it is inventory. PHP execution on a host with a real domain, a valid TLS certificate and clean hosting IP space is exactly what layer 7 attacks need in order to look legitimate. The same box serving a dentist's homepage can be drafted into an HTTP GET flood or HTTP POST flood, held open with Slowloris, hammered through a TLS flood or connection flood, or pushed into HTTP/2 Rapid Reset. Add browser emulation, headless browser farms, JS challenge bypass and CAPTCHA bypass, and the traffic survives JA3 fingerprint and HTTP/2 fingerprint checks, with user-agent rotation keeping the logs messy.

L3/L4 capacity comes from the same pool: SYN flood, ACK flood, ACK-PSH flood, TCP handshake flood, UDP flood, UDP PPS flood, fragmentation flood, and UDP amplification through DNS, NTP, SSDP or CLDAP. None of it needs a datacenter — it needs volume, and a mass WordPress compromise delivers volume. That inventory is then rented out through any ip stresser, booter or ddos service front end, priced per second and settled however the operator prefers. The records we hold were built on exactly this kind of supply chain.

Botnet of compromised WordPress sites launching HTTP flood and layer 7 attacks against a target
Cheap shells, clean IPs, rented by the second.

Patch, then verify

Blocking web access to wp-content/upgrade before updating is the cheapest fix available, and it does not break updates because WordPress touches that folder directly on disk. Manual updates performed outside the web root avoid the temporary installer entirely; wp core update does not, because WP-CLI runs the same updater into the same directory. Sites on 4.6 or earlier have no fix at all — the flaw reaches back to 2.7 — and should be migrated.

After patching, audit. Look for orphaned directories under wp-content/upgrade, unexpected administrator accounts, modified wp-config.php, and outbound scanning or flood traffic leaving the host. "We patched" is not a clean bill of health; it is a timestamp.

Auditing a WordPress site after patching CVE-2026-119977 and blocking wp-content/upgrade
Verify the patch, then verify the host.

Assume the window was used

Every mass compromise of a CMS becomes capacity somewhere downstream, and the operators buying that capacity do not care whether the shell came from a phishing kit or a nine-second TOCTOU race during a routine update. They care that the IP is clean, the certificate is valid and the request looks like a browser. That is the whole game.

If you want to know how much of that traffic your edge absorbs before it folds, our free stress test at /contact is the honest way to find out — no sales call, no dashboard theatre, just packets and a report.