On November 3, 2026, CISA added vulnerability CVE-2026-119977 to the Known Exploited Vulnerabilities (KEV) catalog. The vulnerability affects WordPress Core — from version 4.7.0 to 7.1.3 — and is a Time-of-check Time-of-use (TOCTOU) race condition that allows an unauthenticated attacker to execute arbitrary code on the server during a full core update. The fix is available in WordPress 7.1.4 and has been backported to all supported branches up to and including the 4.7 series. U.S. federal civilian agencies are required to remediate the vulnerability by November 6, 2026.
Technical essence of the vulnerability
According to the official WordPress security advisory, during a full core update (complete-package update), the extracted files are placed in a predictable directory inside a web-accessible update folder. An attacker who wins the race against the extraction process can gain access to intermediate files — in particular, to the installer path setup-config.php — and achieve remote code execution without any authentication on the site.
The vulnerability is classified as CWE-367 (TOCTOU Race Condition). According to Wordfence, it has been assigned a CVSS score of 8.1 (High) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The high attack complexity (AC:H) reflects the need to hit a narrow time window during the update.
Discrepancy in severity assessment
It is worth noting a significant discrepancy between sources. The original WordPress advisory dated October 29, 2026 marks the issue as Low severity and states “No known CVE”. Later — on October 31 — the entry in the GitHub Advisory Database already records the identifier CVE-2026-119977 and classifies the vulnerability as High. Wordfence confirms the 8.1 rating. Thus, the 8.1 score is the assessment by Wordfence and the GitHub Advisory Database, not the vendor’s own assessment in the initial advisory.
Affected versions
The vulnerability covers all WordPress Core branches from 4.7 to 7.1.3. According to the WordPress advisory, the following are also affected:
- 7.1.0–7.1.3, 7.0.0–7.0.7
- 6.9.0–6.9.10, 6.8.0–6.8.11, 6.7.0–6.7.10
- 6.6.0–6.6.10, 6.5.0–6.5.13, 6.4.0–6.4.13
- Earlier branches up to and including 4.7.0–4.7.38
The fix was released in WordPress 7.1.4, and patches have been backported to all of the branches listed above.
Evidence of exploitation
According to Wordfence, over a rolling 24-hour period, 18,762 attacks targeting this vulnerability were blocked. This is a snapshot of telemetry, not the cumulative total of the campaign — the figure changes with each update.
Independently of Wordfence, Previdian recorded three exploitation attempts on its honeypot sensors from a single IP address geolocated in the United Kingdom. The first attempt is dated October 30, 2026. At the same time, Previdian explicitly notes: observations on the sensors confirm exploitation attempts but do not prove that the target system was vulnerable or that the attack succeeded.
There is no attribution: none of the available sources links the observed activity to a specific threat actor group, campaign, or particular victim set.
Impact assessment
WordPress remains the dominant CMS, and a vulnerability in the core — rather than in a plugin — automatically expands the attack surface across all installations using affected versions. We have previously analyzed vulnerabilities directly in the WordPress core: the critical LFI CVE-2026-87902 and the Click2Shell vulnerability. CVE-2026-119977 continues this trend but with an important nuance: the exploitation window is limited to the moment of update.
The paradox of the situation is that the vulnerability is triggered precisely during an update — an action administrators perform to improve security. This creates a risk for sites with automatic updates, as well as for those updated manually without controlling network access to the update directory.
Recommendations
- Update WordPress immediately to version 7.1.4 or the corresponding patched release for your branch. The list of fixed versions is published in the WordPress security advisory.
- Control access to the update directory. Since exploitation depends on accessing predictable paths in a web-accessible update directory during the update process, restricting network access to these paths (for example, via web server rules or a WAF) reduces risk even before applying the patch.
- Monitor requests to intermediate update files. Requests to paths such as
setup-config.phpin the update directory outside the context of a legitimate update are an indicator of an exploitation attempt. - Perform updates under restricted-access conditions: where possible, switch the site to maintenance mode or limit inbound traffic for the duration of the core update.
Adding CVE-2026-119977 to the CISA KEV catalog confirms that the vulnerability is being exploited in practice and is not merely theoretical. WordPress site administrators should prioritize updating to a fixed version — and at the same time ensure that the update process itself takes place in a protected network environment with restricted external access to the server.
