WordPress Bug Strikes While Your Site Updates, 63,000 Tries a Day
Wordfence blocked 62,969 attempts in 24 hours against a WordPress core race-condition bug (now CVE-2026-119977, CVSS 8.1, in CISA KEV) that affects 4.7 through 7.1.3 during core upgrades. 7.1.4 fixes it.
Attackers are already trying to exploit a WordPress core bug that was patched on Oct. 28. Wordfence told The Hacker News it blocked 62,969 attempts in 24 hours. The bug sits in the core software itself, not a plugin, so it affects every site from version 4.7 through 7.1.3. To pull it off, an attacker has to catch a site in the few seconds while it’s installing a core update.
Update, Nov. 4: the bug now has an ID, CVE-2026-119977, and CISA added it to its Known Exploited Vulnerabilities catalog, The Hacker News reports. Federal civilian agencies must fix it by Nov. 6. CISA says unauthenticated attackers could run code on the server during the upgrade window, through predictable, web-accessible staging paths. Wordfence counted more than 18,500 requests for staged setup-config.php installer paths in the first 21 hours after disclosure, and a honeypot run by Previdian logged three attempts on Oct. 30. Successful break-ins still haven’t been publicly reported.
For defenders
The flaw: CVE-2026-119977 (assigned after disclosure). WordPress also tracks it as GHSA-4w3m-c66w-69mg, rated CVSS 8.1. During a full-package core upgrade, WordPress unpacks the new release, installer included, into a predictable folder under wp-content/upgrade/. If that folder can be reached over the web and runs PHP, an unauthenticated attacker who requests the staged installer at the right moment can work it through to PHP code execution. That’s T1190 (Exploit Public-Facing Application). Wordfence says the window lasted only seconds in its lab, and the files are deleted once the upgrade finishes.
Status: added to CISA’s KEV catalog on Nov. 3 (federal due date Nov. 6); EPSS 1%, and two GitHub proof-of-concept repositories are reported. Mass exploitation attempts are confirmed by Wordfence. Successful compromises haven’t been reported yet. Two of the busiest sources kept polling small groups of sites for about 14.5 hours, which Wordfence reads as trying to catch the upgrade window, and others cycled through staging-folder and version-name variations, hitting paths like setup-config.php. No attacker IPs or payloads were published.
Fix: WordPress 7.1.4. Note the irony: the risky moment is the update itself, so a site that auto-updates without protection is briefly exposed while it installs the fix. Wordfence’s write-up has the details.
Requests to PHP files under /wp-content/upgrade/ (e.g. …/wp-admin/setup-config.php inside a staged release folder)What it means for you
WordPress runs a huge share of the web, including most small-business sites. This bug lets a stranger take over a site, but only by catching it in the few seconds while it updates itself, so attackers are knocking on doors constantly. If someone else runs your site, ask them to confirm it’s on 7.1.4. If you run it yourself, the steps below take five minutes.
Do this now
- Update to WordPress 7.1.4 now (Dashboard → Updates), and confirm the version afterward.
- Block web access to
wp-content/upgrade/, or at least stop PHP from running there, in your server or firewall rules. - Check for admin accounts, plugins or PHP files you don’t recognise, and search your logs for requests to PHP files under
wp-content/upgrade/.
CVE at a glance
- CVSS
- 8.1 High (v3.1)
- EPSS
- 1% chance of exploitation in the next 30 days (higher than 63.5% of CVEs)
- Exploited in the wild
- Yes, on CISA’s KEV list since Nov 3, 2026
- Public exploit
- Yes, reported in 3 GitHub repositories
Data from NVD, FIRST EPSS and CISA KEV, refreshed automatically. We report whether public exploit code exists but never link to it: fake proof-of-concepts that infect researchers are common.