SecurityThreats & vulnerabilitiesNote
Updating WordPress opened a hole for seconds; a firewall logged 18,500 probes in 21 hours
WordPress 7.1.4 of 28 October, Wordfence’s count of attack attempts and CISA’s 3 November listing: how the update race works, who is exposed and what to check, as of 4 November.
CISA added a flaw in WordPress itself to its catalogue of exploited vulnerabilities on 3 November, and gave US federal agencies until 6 November to fix it and to check whether they had already been compromised.15 CVE-2026-119977 opens only while WordPress updates. In versions 4.7 to 7.1.3, a full-package core update uses “predictable, web-accessible staging paths” that let unauthenticated attackers “execute code on the server during the upgrade window”.1 WordPress fixed it in 7.1.4 on 28 October, with releases for every older branch back to 4.7.23
18,500+
requests for staged installer paths in the first 21 hours of Wordfence's firewall rule
The first came nine minutes after the rule went live on 28 October. Two sources polled small groups of sites for about 14.5 hours.4
01A race the attacker runs again and again
For a few seconds, an update leaves a copy of WordPress, installer included, where anyone can request it
How CVE-2026-119977 works in WordPress 4.7 to 7.1.3, and what 7.1.4 changed
- 01
The update unpacks
A full-package core update unpacks the new WordPress into a predictable folder under
wp-content/upgrade. - 02
The installer is exposed
The staged copy includes the installer,
setup-config.php. On many servers that folder can be reached from the web. - 03
The race
A request that reaches the installer before WordPress cleans up can lead to PHP code execution. No account needed.
- 04
The fix
7.1.4 randomises the folder name, adds an index guard and stops unsafe promotion of staged configuration data.
Source: Wordfence, 29 October 2026; CISA KEV entry, 3 November 2026 · as of 4 November 2026
In Wordfence’s lab the folder stayed open “only seconds”. Wordfence rates the flaw 8.1 of 10 and calls the attack complexity high: the attacker needs a full-package update, web access to the folder, its path, and time to finish before cleanup. One request is unlikely to land; automated polling improves the odds, which is what Wordfence’s firewall saw. Its count is of requests to its customers’ sites, and not every one used the exact vulnerable path.4
02Who is exposed, and what is not known
WordPress runs 39.5% of all websites, by W3Techs’ count on 4 November.6 Of the sites that report to WordPress.org, 65.2% run the 7.1 branch; 33.9% run 4.7 to 7.0 and need their own branch’s release; 1.0% run 4.6 or older, which get no security fixes at all.73 WordPress.org does not publish how many are on 7.1.4 itself. No compromise has been confirmed in public: Wordfence reports attempts, and neither WordPress nor CISA names a victim.14
03What to check
- The version on your branch. Dashboard, then Updates: 7.1.4, or your branch’s release (7.0.8, 6.9.11, 6.8.12, down to 4.7.39). Automatic background updates should have applied it; Wordfence advises checking rather than assuming.34
- The logs, if a site stayed unpatched: requests to PHP files under
wp-content/upgrade, and administrators, plugins or PHP files you did not add.4 - The firewall. Wordfence’s paying customers got a rule at 20:30 UTC on 28 October, about three hours after the release; free users get it on 27 November. The exploit calls a PHP file directly, so a plugin firewall must run before that file loads (Wordfence’s “Extended Protection”). A rule does not replace the update.4
The same week brought a second update-path incident of a different kind. OPSSHIELD says an attacker used stolen credentials on 2 November to push a malicious script through the update channel of cPGuard, OPSSHIELD’s web-server security product (versions 5.88.12 to 5.88.19); the script collected password hashes and root SSH files. It asks customers to move to 5.88.25 and rotate credentials.9
Sources
- CISA, Known Exploited Vulnerabilities catalogue, JSON feed (CVE-2026-119977 added 3 November, due 6 November) — 3 November 2026
- WordPress.org, WordPress 7.1.4 — 28 October 2026
- WordPress.org Documentation, Version 7.1.4 (security fixes and branch releases) — 28 October 2026
- Wordfence, WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release — 29 October 2026 Updated 30 October.
- CISA, BOD 26-04 implementation guidance (forensic triage) — 10 June 2026 Updated 25 August.
- W3Techs, Usage statistics of WordPress — 4 November 2026
- WordPress.org, version statistics API (share of sites by branch) — read 4 November 2026
- CERT-In, Directions under section 70B(6) of the IT Act, 2000 (Annexure I, item iv) — 28 April 2022
- OPSSHIELD, cPGuard security advisory: Update channel compromise — 3 November 2026
Disclosure. TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.
Keep reading
