A race condition hiding inside WordPress’s own update mechanism is now under active exploitation, and the clock is ticking. On November 3, 2026, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalog, giving U.S. federal civilian agencies until November 6 to patch — but every WordPress site operator should treat the deadline as their own.
What Happened
Security researcher Umut Bayram discovered a time-of-check time-of-use (TOCTOU) race condition in WordPress Core’s full-package upgrade process. The vulnerability, classified as CWE-367, carries a CVSS 3.1 score of 8.1 (High) and affects every WordPress release from version 4.7 through 7.1.3.
WordPress released version 7.1.4 on October 28, 2026, with security fixes backported all the way down to version 4.7.39. Within nine minutes of Wordfence deploying its blocking rule that same evening, the first scanning request arrived. By the time CISA issued its advisory six days later, attackers had already been hammering sites for nearly a week.
Inside the Race Condition
The vulnerability turns the update button itself into an attack surface. When a WordPress site runs a full-package core upgrade, the CMS extracts the new release into a staging directory beneath wp-content/upgrade. In affected versions, that staging path is predictable and — critically — reachable from the web while the upgrade is in progress.
Among the staged files is setup-config.php, WordPress’s installer. During the brief window between extraction and cleanup, an unauthenticated attacker who can guess the staging path can hit that installer directly, bypassing the running WordPress installation entirely. If the timing is right, they can progress to arbitrary PHP code execution in the web server’s context — no credentials, no authentication, no user interaction required.
In Wordfence’s lab testing, the staging directory existed for only a few seconds. But attackers compensate with volume: automated scripts continuously poll candidate staging paths for hours, waiting for the moment a target begins its update. It’s a numbers game, and with WordPress powering over 40 percent of the web, the numbers are in the attackers’ favor.
Exploitation by the Numbers
The scale of scanning has been staggering. Wordfence recorded more than 18,500 requests targeting staged setup-config.php paths within the first 21 hours after disclosure. Two large scanning sources polled small clusters of sites continuously for roughly 14.5 hours each. By November 4, Wordfence was still blocking over 12,600 attempts per day. GBHackers independently reported nearly 59,000 blocked attempts within the first 24 hours of their monitoring.
Honeypot data from Previdian logged three exploitation attempts on October 30 — two days after the patch dropped — originating from a U.K.-geolocated IP address. No public proof-of-concept exploit has appeared in code repositories, but the volume and consistency of scanning strongly suggests that working exploit tooling is circulating privately.
Why This Vulnerability Is Different
Most WordPress vulnerabilities live in plugins and themes. This one is in WordPress Core itself, making the blast radius enormous. Every self-hosted WordPress installation in the affected version range is potentially at risk — and the irony is bitter: you become vulnerable precisely when you’re trying to do the right thing by updating.
The TOCTOU pattern also makes traditional defenses tricky. The race window is so brief that a WAF rule has to be in place before the request arrives — once the staging directory is live, there may be only seconds to act. Rate limiting helps, but a single well-timed request is all an attacker needs if the path prediction is correct.
It’s worth noting that this is the second critical WordPress Core RCE flaw in two months. CVE-2026-87902, a separate vulnerability also affecting WordPress 4.7 through 7.1.x, drew over 30,000 scanning IPs and 322,000 attack signals in September 2026. The frequency of core-level vulnerabilities underscores the growing scrutiny — and attack pressure — on the platform that underpins nearly half the web.
What the Patch Does
WordPress 7.1.4 addresses the flaw through three key changes. First, staging directory names are now randomized, making path prediction significantly harder. Second, an index guard prevents direct web access to staged content. Third, the upgrade process no longer promotes staged configuration data in an unsafe manner. Fixes have been backported from 7.1.4 down to WordPress 4.7.39, though sites running WordPress 4.6 or older are end-of-life and no longer receive security patches.
What You Should Do Now
Verify your version immediately. Navigate to Dashboard → Updates and confirm you’re running 7.1.4 or the patched point release for your branch. Don’t assume automatic updates ran — they can be disabled in wp-config.php, blocked by hosting configurations, or simply delayed.
Audit your infrastructure. Forgotten staging environments, development copies, and legacy installations are all potential targets. Any WordPress instance in the 4.7–7.1.3 range that has ever run a full-package upgrade could have been hit during the race window.
Check for compromise indicators. Review access logs for requests to PHP files under wp-content/upgrade. Look for unfamiliar administrator accounts, unknown plugins, unexpected PHP files in server directories, and unusual outbound connections from your web server. Correlate any suspicious activity with upgrade timestamps.
Harden the upgrade path. Advanced operators can temporarily block web access to /wp-content/upgrade/ at the server or firewall level during updates, though this is a stopgap — only the patch eliminates the vulnerability. Ensure your WAF rules inspect direct requests to staged PHP files.
If you suspect compromise: Rotate all credentials the PHP process could access — admin accounts, database passwords, API keys, and hosting credentials. Preserve logs before any remediation, isolate the host, and restore from a known-clean backup taken before October 28.
What to Watch Next
CISA’s November 6 deadline for federal agencies will come and go, but the broader internet will take longer to catch up. WordPress’s long tail of outdated installations means this vulnerability will likely be exploited for months. The absence of a public PoC actually makes the current period more dangerous, not less — it suggests that exploitation tooling is being kept private for operational advantage rather than released for research.
With two critical Core RCE flaws in eight weeks, the WordPress security team faces growing pressure to rethink how the upgrade mechanism handles temporary files. Until then, the advice is straightforward: patch now, verify it took, and check your logs. The update button should make you safer — not hand attackers a window to your server.
Leave a Reply