Attackers Are Camping on WordPress Update Windows. CISA Just Made It Official.
CISA has added CVE-2026-119977, a WordPress Core vulnerability that opens for a few seconds during a site update, to its Known Exploited Vulnerabilities catalog. Attackers have been camped outside that window since late October.
What Happened?
WordPress 7.1.4 shipped on October 28 with fixes for 22 bugs. The worst one, CVE-2026-119977 (CVSS 8.1), hits every release from 4.7 through 7.1.3.
How the Upgrade Window Opens
During a full package core update, WordPress unpacks new files into a predictable folder under wp-content/upgrade. That staged copy carries the installer, setup-config.php, and no wp-config.php of its own, so the installer runs. Request it at the right moment and an attacker can walk the staged copy to PHP code execution. No account needed. CISA listed it on November 3.
A few seconds open. Hours of someone watching.
During a full package core update, WordPress 4.7 through 7.1.3 stages the new release in a folder anyone can guess. The installer inside it is reachable until the copy finishes.
wordpress-7.1.4.zip/wp-content/upgrade/wordpress-7.1.4/…/wp-admin/setup-config.phpwindow closesWordPress 7.1.4 randomizes the staging folder. But your last update to 7.1.4 still runs on the old code, so block PHP under wp-content/upgrade before you click Update.
By the Numbers
- 9 minutes: the gap between a new firewall rule going live on October 28 and its first hit.
- 18,500+: requests aimed at staged setup-config.php paths in the first 21 hours.
- 14.5 hours: how long the two busiest sources kept polling the same small groups of sites.
- 12,632: attacks blocked in one 24-hour period, per the latest count.
- 3: attempts against one vendor’s honeypots from a UK address on October 30.
- November 6: the patch deadline for US federal civilian agencies.
The window is tiny. The traffic is not.
Probing started almost as soon as the fix shipped, and the busiest sources behaved like they were waiting for an update to begin.
Attempts, not confirmed takeovers. No successful compromise has been reported yet, which is exactly the moment to patch.
Why a Few Seconds Is Enough
WordPress rates the race itself Low because the window is so short. Attackers clearly disagree. They don’t need luck; they need patience, and scripts have plenty. One more catch: your old, unpatched code unpacks the jump to 7.1.4, so that final update can open the window one last time.
What’s the Impact?
Win the race and you get code running with the web server’s privileges. That’s enough for a webshell, a rogue admin, or stolen database credentials, the same end state as other PHP remote code execution flaws. Strong passwords and MFA don’t help here because the attack never goes near the login page. No confirmed takeovers have been reported yet. It also lands on a big target. Most WordPress sites already run outdated code, and attackers have moved quickly through other CMS and web server flaws this year.
How to Avoid This
Patch and Close the Window
- Update to 7.1.4 or your branch’s security release, then confirm the version under Dashboard, Updates.
- Before that update runs, block web requests to PHP files under wp-content/upgrade at the web server.
Hunt for Signs of Compromise
- Search access logs since October 28 for setup-config.php or other PHP files under wp-content/upgrade, and focus on 200 responses.
- Hunt for admin accounts, plugins, or PHP files nobody on your team added, and confirm wp-config.php is still your own.
- Alert when PHP-FPM or Apache starts sh, curl, wget, or python.
Indicators of Compromise
CISA, WordPress, and the researchers tracking the attacks have not published any IP addresses, file hashes, or user agents. What defenders do have is behavior: repeated requests for staged installer paths, sent straight to a PHP file without loading WordPress first. We’ve put those behavioral indicators and ready log searches in a separate sheet.
Your Update Window Is Someone Else’s Attack Window
Annual pentests and quarterly scans won’t catch a hole that stays open for seconds. Attackers poll for hours, so your checks need to run on their clock and prove what is actually reachable.
- Red Teammate probes your internet-facing WordPress sites from the outside, the way these pollers do, and reports only what it can reproduce.
- Infrastructure Security Teammate keeps a live list of every WordPress install, its version, and whether the internet can reach it.
- SOC Teammate turns odd requests to wp-content/upgrade into a case with the asset and its owner attached, not another raw alert.
- Every fix goes back to Red for a retest, so patched means the way in no longer works, not that a version number changed.
- Consequential actions still wait for a named person to approve them.
Patched is a claim. Re-attacked is proof.
Most teams close this ticket when the version number changes. The attacker only cares whether the staged installer still answers.
Scan, patch, close
- 1Scanner flags WordPress 7.1.3
- 2Someone clicks Update
- 3Scanner sees 7.1.4, ticket closes
- ?Nobody checked the update window itself, or what ran during it
Prove, fix, prove again
- 1Probe every internet facing site the way the pollers do
- 2Block PHP under wp-content/upgrade, then update, with a named approver
- 3Turn upgrade path requests into a SOC case with owner context
- 4Re-run the probe. Closed only when the way in fails
A re-scan tells you the setting changed. A re-attack tells you the door is shut.