CVE-2026-119977 is a race condition in the WordPress core upgrader, and attackers are exploiting it right now. CISA added it to its Known Exploited Vulnerabilities catalog on November 3 and gave federal agencies until today, November 6, 2026, to patch.
Any site on a core version before 7.1.4 is exposed unless its branch has received a security backport. That is a lot of sites: sources citing the CVE record put the affected range at 4.7 through 7.1.3.
Updating core fixes it. I would also block web access to wp-content/upgrade/. The attack happens in that folder, and nothing legitimate ever needs to load it over HTTP.
What the attacker actually does
During a full core update, WordPress unpacks the new release into a temporary folder under wp-content/upgrade/. On affected versions, the path of that staging folder is predictable and reachable from the web.
If the server allows PHP to run in that folder, an unauthenticated attacker can reach the staged setup-config.php installer in the few seconds before WordPress cleans up. This is the “upgrade window” from the official 7.1.4 release post, which describes the bug as “a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window.”
Because it is a timing attack, BleepingComputer rates it high complexity. That has not slowed attackers down. BleepingComputer reports that Wordfence blocked 13,095 attacks on it in 24 hours.
Step 1. Check which core version you run
Over SSH, from the WordPress root:
wp core versionIt should print 7.1.4 or newer. If you are deliberately on an older branch, check whether that branch has its backport yet. As of 2026-11-06, the WordPress.org post says the fix is being backported to every branch down to 4.7, and those releases “will ship as they become ready.”
With several sites on one server, loop over them. Change the path to match your layout:
for d in /var/www/*/public_html; do
echo "$d: $(wp core version --path="$d")"
doneStep 2. Block web access to wp-content/upgrade
WordPress writes to this folder through PHP on the server, never through browser requests. Denying HTTP access therefore does not break updates, and it closes the hole even while an update runs. Add the block before you update, so the update itself does not open a window.
On nginx, add this to the server {} block, above your location ~ \.php$ block. Then test the config and reload:
location ^~ /wp-content/upgrade/ {
deny all;
return 403;
}nginx -t && systemctl reload nginxnginx -t should say the syntax is ok and the test is successful. If it reports an error, the reload does not run. Fix the error and run it again.
Keep the ^~ modifier. Without it, nginx can match the PHP regex location first and execute the file anyway.
On Apache, put the rule in the virtual host. Nothing that writes to the site files can remove it from there:
<Directory "/var/www/html/wp-content/upgrade">
Require all denied
</Directory>If .htaccess is all you can edit (typical on shared hosting), add this to the .htaccess in the WordPress root, above the # BEGIN WordPress block:
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]Test it with curl -I https://example.com/wp-content/upgrade/. The response should be 403.
Step 3. Back up and update core
Back up the database and the files first. Then run the minor update:
wp db export before-7.1.4.sql
wp core update --minor
wp core versionThe last command should now print 7.1.4, or your branch’s backport release. If WP-CLI reports that another update is in progress, an earlier attempt left a stuck lock behind. Another Update Is Currently in Progress shows how to clear it.
💡 Minor core updates install automatically by default. If wp-config.php sets WP_AUTO_UPDATE_CORE to false, or a plugin switched auto updates off, your site did not get 7.1.4 by itself. Check this before you assume you are patched.
Check whether someone got in before you patched
A blocked attempt is not a compromise, and as of today nobody has publicly named a compromised site. Still, this is a code execution bug that attackers are scanning for at mass scale, so ten minutes of checking is worth it.
First, search your access logs for requests to PHP files in the upgrade folder. The path below is for nginx; use your Apache log path instead if you run Apache:
zgrep -hE "wp-content/upgrade/.*\.php" /var/log/nginx/access.log* | sort | uniq -c | sort -rn | headNo output means nobody requested PHP there in the logs you still have. The lines that matter are the ones with a 200 response. A 403 or 404 means the request failed.
Next, check the folder, the core files and the admin accounts:
find wp-content/upgrade -type f -name "*.php"
wp core verify-checksums
wp user list --role=administrator
ls -l wp-config.php- When no update is running,
wp-content/upgradeshould not contain PHP files you cannot account for. verify-checksumsshould finish with a success line saying the install verifies against checksums. Look at every file it reports as modified or unexpected.- You should recognize every administrator in the list.
- If wp-config.php was modified at a time you did not edit it, read it closely, especially the database credentials.
If anything looks wrong, treat the site as hacked. Rotate passwords and salts, then work through my complete clean-up guide. A core reinstall with WP-CLI replaces the core files quickly.
Doing the same in OpenPanel
In OpenPanel you can add the nginx or Apache block from Step 2 without SSH. The Edit VHosts File page edits the domain’s web server config directly, checks the syntax, and rolls back automatically if the new config fails. On cPanel you usually cannot edit the vhost yourself, so on cPanel shared hosting the .htaccess rule is the way to go. To update core, OpenPanel’s WordPress Manager has a bulk action that updates core on all the sites you select.
Keep the upgrade folder from becoming a target again
The deny rule costs nothing and stays useful after you patch, so leave it in. The bigger takeaway is that weeks like this are why minor auto updates exist. Keep them on unless your own process patches faster.
While you are in the server config, make sure PHP cannot run anywhere under wp-content/uploads either. It is the same class of mistake: a writable folder that the web server will execute code from.
TL;DR: CVE-2026-119977 lets attackers run code through the staged installer in wp-content/upgrade/ while a core update runs, and it is under active exploitation. Block that folder at the web server, update to 7.1.4 or your branch’s backport, then check your logs, core checksums and admin users.
