Short answer: CVE-2026-119977 is a race condition in the WordPress core updater itself. While a full-package core upgrade is unpacking, an unauthenticated attacker can reach the staged files in a predictable directory under wp-content/upgrade/ and get code executed. It affects WordPress 4.7.0 through 7.1.3, it is fixed in 7.1.4 and in backports down to 4.7.39, and CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2026 with a federal remediation deadline of 6 November. If you host WordPress, the task is not only to patch but to know every installation you have, including the ones nobody told you about.
Why This One Is Unusual
Most WordPress advisories name a plugin. This one names the core software, and more specifically the part of it that everybody is told to use: the update mechanism.
When WordPress applies a core update from a complete package rather than an incremental one, it downloads the archive, unpacks it into a working directory beneath wp-content/upgrade/, and then moves the new files into place over the live installation. In affected versions that working directory has a predictable name, and it sits under the document root where the web server will happily serve what it finds. The vulnerability is classified as a time-of-check time-of-use race, CWE-367: between the moment the files are staged and the moment they are promoted, a request that arrives with the right path gets to interact with content that is not yet the vetted, installed copy.
The practical consequence is that the attack window opens during the upgrade. It is short, it is not something an attacker can schedule, and it does not require any account on the site. It does require the attacker to be looking at the right moment, which is why automation and mass scanning matter here: a crawler that polls a predictable path across a large number of sites will eventually catch one mid-update.
What 7.1.4 Changed
The fix released on 28 October 2026 does three things:
- The staging directory name is randomised, so the path cannot be guessed in advance.
- An index guard is added, so the directory cannot be browsed even if the path is known.
- Staged configuration data is no longer promoted in a way that can be abused during the window.
Because the affected range starts at 4.7.0, the WordPress security team backported the fix across every supported branch, producing fixed releases as far back as 4.7.39. That is deliberate: a large number of production sites run old branches on purpose, and telling all of them to make a major version jump during an active exploitation campaign would have slowed the response down.
The Minimum You Need to Do
1. Get every site to a fixed version
A site is safe when its core version is 7.1.4 or newer, or when it is on the fixed release of its own branch. On a single site:
wp core version
wp core updateWordPress sites that have automatic background updates enabled for core will generally have taken the fix already, because security releases are pushed through that channel. Sites where background updates were switched off, or where WP_AUTO_UPDATE_CORE was set to false or to minor on a branch that needed a different release, are the ones that are still sitting on an affected version.
2. Find the installations you forgot about
This is the part that catches hosts out. The WordPress you know about is in the document root. The ones that bite are in /blog, in a subdomain that was set up for a campaign in 2022, in a staging copy somebody made before a redesign and never removed, or inside a customer account that was migrated in from another panel with its own directory layout.
On a single server, the direct approach is to look for configuration files rather than for directories:
# every WordPress installation on the machine
find /home -maxdepth 6 -name wp-config.php -type f 2>/dev/null
# and the core version of each one
for c in $(find /home -maxdepth 6 -name wp-config.php -type f 2>/dev/null); do
d=$(dirname "$c")
v=$(grep -m1 "wp_version =" "$d/wp-includes/version.php" 2>/dev/null | cut -d"'" -f2)
printf '%-14s %s\n' "${v:-unknown}" "$d"
done | sortSort the output and read the left column. Anything below 7.1.4 that is not the fixed release of its own branch needs attention, and anything that prints unknown needs a human to look at it.
3. Check whether the window was used
Exploitation leaves traces in the upgrade directory and in access logs. After patching, look for files that should not have survived an update, and for requests to upgrade paths:
# leftovers in the staging area
find /home -maxdepth 8 -path '*/wp-content/upgrade/*' -type f 2>/dev/null | head -50
# requests that went looking for the staging path
grep -h 'wp-content/upgrade' /var/log/nginx/*access*.log /var/log/apache2/*access*.log 2>/dev/null | tail -50A normal, completed update leaves that directory empty or close to it. PHP files sitting in it, especially with recent timestamps and names that look generated, are worth treating as an incident rather than as clutter.
Does This Affect a Panelica Server?
WordPress is WordPress wherever it runs, so yes: a WordPress installation on a Panelica server is affected if its core version is in the vulnerable range. No control panel can patch a race condition that lives inside the application's own updater. What a panel can do is remove the two practical obstacles to responding, and that is worth being precise about.
Finding every installation. Panelica's WordPress manager does not rely on an inventory that somebody remembered to fill in. It walks the account's tree and reports every wp-config.php it finds, whether the site is in the document root, in a subdirectory, or under a subdomain, and it can do that across multiple domains in one bulk scan. Installations it discovers can be imported and then managed alongside the ones the panel created. That matters here because the installations most likely to be unpatched are exactly the ones nobody had a record of.
Seeing and changing the version. Each managed installation shows its core version, whether a core update is available, and whether automatic core updates are enabled for it. Updating runs WordPress's own tooling through WP-CLI, as the site's own system user, followed by the database update step. It is the same upgrade WordPress would perform on its own, executed under the account that owns the files rather than as root.
Limiting what a successful exploit reaches. This is where hosting architecture earns its keep. On Panelica, each hosting account runs its websites in its own PHP-FPM pool, under its own system user, with open_basedir restricted to that account's home directory plus the shared read-only locations PHP needs, and with the process execution functions disabled in PHP: exec, passthru, shell_exec, system, proc_open and popen. Code that gets executed in one site's context therefore starts out inside one account, without a shell, and without read access to other customers' files. That does not make an exploited site acceptable. It does mean the difference between one site to clean up and a server to rebuild.
If you manage WordPress for other people and this advisory sent you digging through directories by hand, that is the problem worth fixing before the next one. See how Panelica discovers and manages every WordPress installation on your servers.
What to Change After You Patch
- Leave automatic core security updates on. For the overwhelming majority of sites this advisory is an argument for background updates, not against them: the sites that were already current when the news broke are the ones that had them enabled.
- Keep a list of installations that is generated, not maintained. Any inventory a human types will be wrong within a quarter. A scan that finds
wp-config.phpwill not be. - Treat staging copies as production. An old copy of a site under
/oldor/devruns the same code with the same database credentials. If it is reachable, it is production. - Watch the upgrade directory. It should be empty between updates. A file monitor that reports anything persisting there gives you a cheap signal for this entire class of problem, not just this CVE.
Frequently Asked Questions
What is CVE-2026-119977?
It is a time-of-check time-of-use race condition in the WordPress core update mechanism, affecting WordPress 4.7.0 through 7.1.3. While a full-package core upgrade stages files in a predictable directory under wp-content/upgrade/, an unauthenticated attacker can reach those files and achieve remote code execution. The CVSS base score is 8.1.
Which WordPress version fixes it?
WordPress 7.1.4, released on 28 October 2026. The fix was backported to every supported branch, with fixed releases down to 4.7.39, so a site on an older branch can take the fix without a major version jump.
Is CVE-2026-119977 being exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2026, confirming evidence of active exploitation, and set 6 November 2026 as the remediation deadline for applicable US federal civilian agencies. Private operators have no deadline, but the same evidence applies to them.
Is a plugin or theme responsible?
No. The weakness is in WordPress core's own upgrade mechanism, not in third-party code. Removing plugins does not address it, and no plugin is required for a site to be affected.
Am I safe if automatic updates are enabled?
Very likely, because core security releases are delivered through that channel, but verify rather than assume. Check the actual version with wp core version on every installation, including ones where WP_AUTO_UPDATE_CORE may have been set to false or restricted to minor updates.
How do I find every WordPress installation on a server?
Search for configuration files rather than directories: find /home -maxdepth 6 -name wp-config.php -type f, then read each installation's version from wp-includes/version.php. On Panelica, the WordPress manager performs the same discovery across accounts and domains and lets you import what it finds.
How can I tell whether a site was compromised during an upgrade?
Look for files left behind under wp-content/upgrade/, which should be empty between updates, and search web server access logs for requests referencing that path. Unexpected PHP files with recent timestamps in the staging area should be treated as an incident, not as leftover clutter.