Wordfence detected probing of the update-window flaw fixed in WordPress 7.1.4 within hours of its release on October 28. The company deployed a firewall rule for it about three hours after the release and recorded the first match nine minutes later. In the first 21 hours after deploying the rule, it counted more than 18,500 requests to the paths where WordPress briefly stages its installer during an update. These figures reflect probing activity, and Wordfence’s report does not describe any successful compromise.

The flaw can let an unauthenticated attacker reach remote code execution by requesting that staged installer while a full-package core update is being unpacked. In Wordfence’s lab tests, the window lasted only seconds. On sites that are still vulnerable, the window reopens with each full-package core update, including automatic ones. Besides the update itself, the protection a host can apply directly is a rule at the web server, which Patchstack recommends.

Key facts

  • Identifier: CVE-2026-119977, published by Wordfence on October 31 with a CVSS score of 8.1. WordPress’s own advisory labels the issue low severity.
  • Affected versions: WordPress 4.7 through 7.1.3. The fix shipped in 7.1.4 and in backport releases down to 4.7.39.
  • Server-side block: Patchstack advises denying web access to wp-content/upgrade/, a rule a host can apply to every site on a server.
  • Firewall timing: paying Wordfence customers received the rule on October 28, and users of the free version receive it on November 27.

Attackers Poll and Wait for the Update

Wordfence’s telemetry shows attackers working around the short window by polling repeatedly. Two of the largest sources polled small groups of sites for roughly 14.5 hours, behavior the company describes as consistent with trying to catch the upgrade window. Other sources tried variations of the staging directory and version names. Not every request used the exact vulnerable path, it notes.

Citing Wordfence data, The Hacker News reported on October 30 that the company had blocked 62,969 attacks targeting the flaw in the previous 24 hours. That figure covers a different 24-hour window and counts blocked attacks rather than requests to specific paths, so it is not directly comparable with the 18,500 requests counted in the first 21 hours.

WordPress 7.1.4 Fixes 22 Flaws, One in the Core Update Process

Why the Severity Ratings Differ

As we reported on October 29, WordPress released 7.1.4 without a severity rating for the flaw. The project’s GitHub advisory, published on October 29, labels it low. The CVE record that Wordfence published on October 31 scores it 8.1, high, with high attack complexity. Patchstack also scored the attack complexity as high and would not call the flaw practical to exploit.

The conditions behind the high attack complexity are specific. According to Wordfence, an attack needs:

  • a full-package core update that contains the installer files
  • web and PHP access to the staging directory under wp-content/upgrade/
  • a staging path that is predictable or can be discovered
  • enough time to finish before WordPress removes the temporary files

Wordfence’s score reflects the eventual impact, code execution on the server.

Where Hosts Can Block It

According to Patchstack, a firewall that loads with WordPress cannot block the attack. The staged copy of WordPress runs its own files, so the site’s normal firewall never handles the request. Patchstack recommends blocking at the web server: deny access to wp-content/upgrade/ and make sure the directory cannot be listed. Between updates, it holds nothing but an index.php file. A host can apply that rule across every site on a server, including sites whose automatic update has not yet run.

For its own rule, Wordfence advises enabling Extended Protection, which lets its firewall run before a direct request reaches a PHP file. The exploit requests the staged PHP file directly, without loading WordPress. The company also stresses that the firewall reduces exposure but does not replace the update. For sites that stayed unpatched, it advises checking logs for requests to PHP files under wp-content/upgrade/ and looking for unfamiliar administrator accounts, unexpected plugins and PHP files nobody placed there.