Summary
- WordPress patched a race condition affecting full-package Core upgrades.
- Wordfence recorded 62,969 blocked attempts targeting the vulnerability over 24 hours.
- Exploitation requires a brief and specific opportunity during an affected upgrade process.
Attackers have been probing a patched flaw in WordPress Core that could expose temporary installation files during some software upgrades, creating a narrow opportunity for unauthorised execution on affected websites. Security company Wordfence says it blocked 62,969 related requests within a 24-hour period.
The issue, assigned CVE-2026-119977 by Wordfence on 31 October, concerns a race condition in the way WordPress stages files while performing full-package upgrades. The underlying flaw was described earlier in a WordPress project advisory, which classified its severity as Low. Wordfence subsequently assessed it as High, with a CVSS score of 8.1.
During particular update operations, installer files could temporarily be extracted beneath the publicly accessible upgrade directory. A remote attacker aware of a likely path could attempt to access such files before the updater completed its work and removed them. The exploit opportunity therefore exists only when several specific conditions coincide.
A target must be running a vulnerable version, performing the affected type of update, and exposing the relevant staging directory to external requests. An attacker’s request must also reach the installation file during the short period when it is present. This differs from an ordinary vulnerability in a permanently available page or API endpoint.
Wordfence observed repeated requests for predictable staging paths, activity consistent with attackers trying to catch that brief update window. The reported count reflects blocked requests detected through its protection systems, not the number of successfully compromised WordPress installations or even the number of unique target websites.
Some scanning sources may send the same request repeatedly for many hours, hoping that the website performs an upgrade while the probe is running. A high number of attempts can therefore indicate widespread automated interest without showing that attackers reached an actual vulnerable installation at precisely the right moment.
The WordPress project supplied corrected releases including WordPress 7.1.4 and security backports for supported earlier branches. Sites should be checked against the fixed version appropriate to the branch in use, rather than assuming that the existence of an update on the platform automatically establishes every deployment has applied it.
Update mechanisms deserve attention because they operate with privileges needed to replace application files. Installation tools may unpack components, create temporary directories, and change file permissions before presenting the new version. When those intermediate artefacts are served by a public web server, code intended only for a trusted installation process may become externally reachable.
The discrepancy between the original project’s Low rating and Wordfence’s later High assessment reflects different published evaluations of the same weakness. It should be reported transparently rather than silently selecting one figure as though it were the sole classification. Actual deployment risk depends on the website’s configuration and upgrade workflow.
For organisations administering many WordPress sites, update automation can create repeated short exposure windows across a fleet. Each site may be vulnerable for only a limited period, but an attacker repeatedly probing common paths may attempt to exploit whichever installation happens to be upgrading at the time.
Monitoring of unusual requests during maintenance can help determine whether a website received suspicious traffic, although a blocked probe is not proof that vulnerable files existed when the request arrived. Successful compromise would require separate evidence from server logs, changed files, or other forensic indicators.
WordPress’s fix addresses the way temporary files are handled during the affected operation. The response is therefore a software correction rather than simply a change to the timing of updates. Administrators also need to ensure that their production instances are running corrected builds, including any sites managed through external hosting services.
The available records confirm active attempts against the upgrade-path flaw and a subsequent CVE assignment. They do not establish a public tally of successful compromises, and the reported request volume must be kept distinct from actual exploitation outcomes.
