CISA confirms attacks on a WordPress core upgrade flaw

On 3 November 2026 the US cybersecurity agency CISA added CVE-2026-119977 to its catalogue of vulnerabilities that are already being used in attacks (Known Exploited Vulnerabilities). The flaw sits in WordPress core itself, in the update process, and affects every version from 4.7 to 7.1.3. It is fixed in WordPress 7.1.4, released on 28 October, and in the security releases for the older branches all the way back to 4.7. US federal agencies have until 6 November to apply it.

The hole is open for only a few seconds, while core is being updated. Attackers do not leave that to chance, though. They check the same sites again and again to catch exactly that moment.

How the attack works

When WordPress updates its core, it first unpacks the new files into a temporary folder inside wp-content/upgrade/ and only then copies them over the site. That folder can be opened from a browser. Up to version 7.1.3, the name of the temporary subfolder came from the package name and was easy to guess, and on a server with directory listing switched on it could simply be seen.

For those few seconds the folder holds a complete copy of WordPress, including the installer setup-config.php, which runs without the site's configuration. According to Wordfence, someone without an account who opens that installer at the right moment can get their own code running on the server. That means full control of the site.

We compared the code of 7.1.3 and 7.1.4. The new version does three things. It gives the temporary folder a name with 16 random characters, places an empty index.php in wp-content/upgrade/ so its contents cannot be listed, and never copies a wp-config.php from the temporary folder over the site. That last change hints at how the attack ends. The installer writes a configuration file, and the update carries it onto the live site.

Wordfence scores the vulnerability 8.1 on the CVSS scale, "high", while noting that the attack complexity is high. WordPress itself rates it low. The CVSS score guide explains what these scores mean. Wordfence saw the first attempts nine minutes after it released a firewall rule on 28 October, and attempts in the first days ran into the thousands. As of late October Wordfence had not reported a confirmed break-in, but CISA only lists vulnerabilities for which it has evidence of attacks.

Which sites are affected

Any site running WordPress 4.7 to 7.1.3 that has not yet received the fix for its branch is affected. The risk comes at the moment WordPress unpacks the whole of core rather than just the changed files. That happens when moving to a new major version, when reinstalling, and when a site skips versions and the small package with only the changes cannot be used.

There is one awkward detail. The update to 7.1.4 runs through the old version's code, because that code is what unpacks the package. If that update uses the full package, the update itself opens the window for the attack. So block the folder first, then update.

Versions 4.6 and older have no fix. WordPress no longer issues security updates for them.

Is your site affected?

You can see the version under Dashboard > Updates. In cPanel's Terminal you can check it with the command below. The WP-CLI guide explains how to work with WP-CLI.

# cPanel > Terminal, in the site's folder
# Read-only. Shows the WordPress version.
wp core version

The fix is in 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11 and the matching releases of older branches down to 4.7.39. If your version is one of these, or newer within the same branch, the hole is closed.

The next command searches the cPanel logs for requests to wp-content/upgrade/. An ordinary visitor has no business there.

# cPanel > Terminal
# Read-only. Requests to the temporary update folder.
zgrep -h "/wp-content/upgrade/" ~/access-logs/* ~/logs/*.gz 2>/dev/null \
  | tail -n 20

Requests there mean someone tried. They do not mean they succeeded. An empty result is a good sign, but the logs only go back a few weeks unless log archiving is switched on.

What to do

1. Block browser access to wp-content/upgrade/. Put the rule below at the top of the .htaccess file in the site's folder, before the WordPress block. Do not put it inside wp-content/upgrade/ itself, because older versions delete everything in that folder on every update.
2. Back up the files and the database, as described in the backup guide.
3. Update from Dashboard > Updates and check the version again with wp core version.
4. Look through Users for administrators you do not recognise and through Plugins for plugins you did not install. If you find anything like that, change the passwords and work through the guide for a hacked site.

# At the top of .htaccess in the site's folder, before # BEGIN WordPress
# Denies browser access to the temporary update folder.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Once the file is saved, open https://your-site/wp-content/upgrade/ in a browser. You should get a 403 error. Updates keep working with the rule in place, because WordPress writes to that folder directly on disk, not through the browser.

What we do

With vulnerability (CVE) monitoring we track what is installed on your site and match it against the vulnerability (CVE) databases every day. As soon as a vulnerability appears in something you use, we send you an alert and update, trying the update on a copy in staging first. Your site can be hosted anywhere. If you would like us to add it, write to us through the inquiry form.

Sources

• CISA, Known Exploited Vulnerabilities Catalog
• NVD, CVE-2026-119977
• WordPress.org, WordPress 7.1.4 Security Release
• Wordfence, WordPress Core 4.7.0 - 7.1.3, Unauthenticated Upgrade Window Staged Installer Remote Code Execution
• GitHub, WordPress 7.1.3 and 7.1.4 compared
• WP-CLI, wp core version