CVE-2026-119977: WordPress Core RCE Flaw Exploited During Software Upgrades

A high-severity vulnerability in WordPress Core is being actively targeted in attacks, prompting the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add the flaw to its Known Exploited Vulnerabilities (KEV) catalog. Tracked as CVE-2026-119977, the vulnerability carries a CVSS score of 8.1 and can allow an unauthenticated attacker to execute arbitrary code on a vulnerable server during a WordPress Core upgrade.

The vulnerability stems from a time-of-check time-of-use (TOCTOU) race condition in the WordPress upgrade process. During full-package Core updates, WordPress temporarily stages installation files in predictable, web-accessible locations. Attackers can repeatedly probe these locations and attempt to reach installer components during the brief period in which an upgrade is taking place.

WordPress addressed the issue in version 7.1.4, released on October 28, 2026. The vulnerability affects WordPress versions 4.7 through 7.1.3, while security fixes have also been backported to eligible older branches. WordPress stresses that only the latest release is actively supported.

The risk has moved beyond theoretical exploitation. Wordfence telemetry cited by The Hacker News recorded more than 18,500 requests targeting staged setup-config.php installer paths during the first 21 hours after disclosure. CISA subsequently confirmed evidence of exploitation and required applicable U.S. federal civilian agencies to remediate the vulnerability by November 6, 2026.

Security teams can use the SOC Prime Platform to strengthen detection coverage against emerging exploitation techniques and hunt for suspicious activity associated with vulnerable internet-facing systems. Detect CVE-2026-119977 exploitation by monitoring abnormal requests to WordPress upgrade locations, unexpected PHP execution, newly created administrative accounts, suspicious files, and post-exploitation behavior.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

Contact Sales

CVE-2026-119977 analysis

CVE-2026-119977 is classified as a TOCTOU race condition under CWE-367 and has a CVSS 3.1 score of 8.1. Its vector reflects network-based exploitation requiring no privileges or user interaction, with high potential impact on confidentiality, integrity, and availability. Attack complexity is rated high because successful exploitation depends on reaching a vulnerable resource during a narrow upgrade window.

CVE-2026-119977 affects WordPress Core releases from version 4.7 through 7.1.3. The weakness is not tied to a third-party plugin or theme; it exists in the Core software upgrade mechanism itself.

The issue occurs during full-package Core upgrades. WordPress temporarily extracts the new package into a staging location beneath the wp-content/upgrade directory before replacing the existing installation. In affected releases, portions of this staging location can be predictable and reachable from the web while the update is underway.

One particularly important component is the staged setup-config.php installer. An unauthenticated attacker who correctly predicts the temporary path and reaches that component before WordPress completes cleanup may be able to interact with the staged installation and ultimately execute PHP code on the server.

This creates an unusual exploitation model. A vulnerable WordPress site is not necessarily continuously exploitable. Instead, the attacker must catch the site during the brief period in which a full-package upgrade exposes the staging files. Researchers indicate that the opportunity may last only seconds.

Attackers can compensate for that limitation through automation. Rather than making a single request, threat actors can continuously poll potential upgrade paths and wait for a target to begin updating. Wordfence observed attackers repeatedly requesting variations of staged installer locations, demonstrating that real-world actors quickly understood how to target the race condition.

The large volume of observed requests should nevertheless be interpreted carefully. The reported figures represent blocked requests or exploitation attempts and do not mean that every request resulted in successful remote code execution. Exploitation still requires the request to coincide with an active full-package upgrade and other required server conditions.

Wordfence’s initial telemetry showed more than 18,500 requests against staged installer paths in the first 21 hours. GBHackers subsequently reported nearly 59,000 attempts blocked within a 24-hour period, while The Hacker News cited additional telemetry demonstrating continued exploitation activity.

Independent honeypot telemetry cited by The Hacker News recorded exploitation attempts on October 30, further supporting CISA’s decision to classify the vulnerability as actively exploited. CISA’s addition of the flaw to KEV significantly raises the urgency for organizations operating public WordPress infrastructure.

At the time of writing, the reviewed sources do not document a broadly available, publicly validated CVE-2026-119977 PoC repository. However, public exploit code is not required to establish risk because exploitation attempts have already been observed at scale and CISA has confirmed active exploitation.

WordPress 7.1.4 changes the vulnerable upgrade process. According to the available technical reporting, the remediation includes making staging locations less predictable, introducing additional protections against direct access, and preventing staged configuration data from being promoted in an unsafe manner.

WordPress credited security researcher Umut Bayram with reporting the upgrade-process weakness. Version 7.1.4 was released on October 28, 2026, and the CVE record was subsequently published on October 31.

For CVE-2026-119977 detection, defenders should pay particular attention to web requests targeting unusual paths beneath wp-content/upgrade, especially requests referencing staged copies of setup-config.php. Repeated requests across multiple possible staging directories may indicate automated probing attempting to win the race condition.

Successful exploitation can potentially provide remote PHP code execution in the context of the affected web server. Defenders should therefore correlate suspicious upgrade-path requests with subsequent evidence such as unexpected PHP files, modification of WordPress configuration data, unfamiliar administrator accounts, malicious plugins, unusual child processes spawned by the web server, or unexpected outbound connections.

Public reporting has not identified a comprehensive set of attacker-specific CVE-2026-119977 IOCs such as stable command-and-control domains or malware hashes. This makes behavior-based detection particularly important. Requests to predictable staging paths, suspicious activity during an update window, and post-exploitation modifications provide more durable hunting opportunities than relying exclusively on static indicators.

CVE-2026-119977 Mitigation

The primary CVE-2026-119977 mitigation is to update WordPress immediately. WordPress 7.1.4 contains the security fix, and fixes have also been made available or backported for eligible older release branches. Organizations should prioritize migration to the latest actively supported WordPress version rather than relying indefinitely on legacy security backports.

Administrators should take the following actions:

1. Upgrade internet-facing WordPress installations to version 7.1.4 or later.
2. Verify that automatic updates completed successfully rather than assuming that an update was applied.
3. Inventory older WordPress installations, including forgotten development, staging, and legacy sites.
4. Review web server and WAF logs for requests targeting wp-content/upgrade and staged setup-config.php paths.
5. Investigate unexpected PHP files, new WordPress administrator accounts, unauthorized plugins, and unexplained configuration changes.
6. Review outbound connections and web-server child processes for evidence of post-exploitation activity.
7. Ensure WAF protections operate early enough in the request path to cover direct requests to temporary PHP files.
8. Consider restricting direct web access to temporary upgrade directories where operationally feasible.

Web application firewall rules can reduce exposure to automated exploitation attempts, but they should not be treated as a replacement for patching. Because the vulnerable resource can exist temporarily outside the normal WordPress request flow, administrators should verify that their WAF deployment actually inspects direct requests to staged PHP files.

Organizations that upgraded while active exploitation was already underway should also consider retrospective investigation. Completing the update removes the vulnerable behavior but does not prove that the server was not compromised while the vulnerable staging directory was available.

Review access logs surrounding the precise upgrade timestamp. Requests to the affected staging paths occurring immediately before or during the upgrade should receive additional scrutiny. Security teams should then correlate those requests with file-system changes, WordPress account modifications, PHP execution, suspicious network connections, and other post-exploitation indicators.

If compromise is suspected, isolate the affected host where practical, preserve relevant web, application, authentication, and system logs, and collect suspicious files before remediation. Credentials and secrets accessible to the WordPress/PHP process should be considered potentially exposed and rotated based on the findings of the investigation.

CISA’s inclusion of the vulnerability in KEV confirms that remediation should be treated as an immediate operational priority rather than a routine patch-cycle item. Federal Civilian Executive Branch agencies were directed to address the issue by November 6, 2026.