Unauthenticated Remote Code Execution in WordPress Core Full-Package Upgrades
CVE-2026-119977 is a time-of-check time-of-use (TOCTOU) race condition in the WordPress Core full-package upgrade process, affecting unpatched releases from 4.7 through 7.1.3. Upgrade packages are extracted into predictable staging directories that can be publicly accessible and permit PHP execution. The staged WordPress copy temporarily exposes an installer without the live site's configuration, while vulnerable cleanup behavior removes a protective directory index. An unauthenticated attacker who reaches the staged installer before cleanup can configure it to use an attacker-controlled database and achieve arbitrary server-side code execution. The exposure window may last only seconds. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on November 3, 2026, based on evidence of active exploitation.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation permits arbitrary PHP code or command execution with the privileges of the web server account, potentially compromising the WordPress installation and resources accessible to that account. Consequences include website takeover, disclosure of database credentials and other secrets, theft or modification of application data, deletion of accessible files, installation of malicious plugins or web shells, and service disruption. Exploitation does not inherently grant operating-system root privileges. Observed request and blocking totals measure exploitation attempts, not the number of successfully compromised websites.
If you can’t patch tonight, do this now.
Temporarily deny direct public web requests to the Core upgrade staging directory through web server, reverse proxy, CDN, or appropriately deployed WAF controls, and disable directory listing. Place restrictions outside the staging tree because vulnerable upgrade routines can remove files stored there. Ordinary WordPress plugin firewalls may be bypassed when requests execute the staged copy directly; any firewall protection must cover PHP execution before the normal WordPress request flow, such as Wordfence Extended Protection. Review requests to staged PHP installers and correlate them with Core upgrade timestamps. These measures supplement rather than replace installation of a fixed release.
Patch, then assume compromise.
Upgrade immediately to WordPress 7.1.4 or a later supported release, and verify successful installation on every production, development, staging, and legacy instance, including installations using automatic updates. Security backports are available for affected older branches, including 7.0.8, 6.9.11, and releases down to 4.7.39; use the fixed release appropriate to the installed branch if immediate migration is not feasible. Migration to the latest supported release is preferred. The fix randomizes staging directory names, preserves an index guard, and prevents unsafe promotion of staged configuration data. Review activity around earlier upgrade windows because patching does not remove an existing compromise. If compromise is suspected, preserve relevant logs, investigate unauthorized changes and persistence, and rotate credentials and secrets accessible to the WordPress process.
1 exploit validated by Mallory's analysis. Hidden: 1 rejected by Mallory's analysis as not a working exploit; 1 not yet analyzed, such as Exploit-DB entries.
123 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.