WordPress: attackers exploit a flaw in the core update process

What happened

WordPress powers a huge share of the web, from personal blogs to WooCommerce shops. CVE-2026-119977 is in WordPress core itself, not in a plugin or theme, so every site on an affected version is exposed regardless of what it has installed.

WordPress released version 7.1.4 on 28 October 2026 as a security release with 13 fixes. The most serious one, credited to researcher Umut Bayram, is described by WordPress as a weakness in the upgrade process "that could lead to remote code execution during the upgrade window". WordPress recommended updating immediately. The CVE record was published in NVD on 31 October, and on 3 November 2026 CISA added it to its Known Exploited Vulnerabilities (KEV) catalog, which means it has evidence of exploitation in the wild.

CISA doesn't say whether ransomware groups are using the flaw, and neither WordPress nor CISA has published how many sites have been hit.

Technical details

According to the NVD record, the problem lies in full-package core upgrades. When WordPress installs a new version from a complete package, it unpacks the files into a staging location first. That location is predictable and reachable from the web. For the few moments the staged copy exists, an unauthenticated attacker who requests it can get code to run on the server.

That's why it's classed as a race condition: the attacker has to hit the staged files after they appear and before WordPress moves or deletes them. NVD's references point to the core upgrader classes in wp-admin/includes/ and to the installer script wp-admin/setup-config.php in 7.1.3, alongside the changed upgrade code in 7.1.4. In other words, the risk sits in the update routine, not in the normal running site.

A few points matter for defenders:

• No login is needed. The CVSS vector has PR:N – no privileges and no user interaction.
• Timing is everything. The attack complexity is rated high (AC:H) because it only works while an update is being unpacked. Patchstack calls the window "extremely small".
• A PHP-level firewall can't stop it. Patchstack notes that no rule in its own firewall can cover it, because the staged files are requested directly. The block has to be at the web server.
• Automatic updates create the window. A site that updates itself in the background goes through exactly this sequence, so the fix has to be in place – or the folder blocked – before the next full-package update.

We're not publishing request patterns that would help someone reproduce the attack. The detection advice below is enough to find suspicious traffic.

Who is affected

Anyone running WordPress 4.7 through 7.1.3: businesses, schools, councils, charities, individuals. According to NVD, you're safe once you have at least the fixed release for your branch:

WordPress backports security fixes to every branch back to 4.7, but it only fully supports the latest version. Treat old-branch releases as a stopgap. Visitors to WordPress sites don't need to do anything.

How to tell if you were compromised

Neither WordPress nor CISA has published official indicators of compromise. Based on how the flaw works, these are the checks we'd run first:

• Access logs. Look for requests to anything under /wp-content/upgrade/, especially .php files. Legitimate visitors and WordPress itself have no reason to fetch files from that folder over HTTP, so any such request deserves a closer look – even if it returned 404. Repeated probing of different subfolders suggests someone is scanning and waiting for an update window.
• Timing. Compare suspicious requests with the times your site updated its core. A successful request during an update is the red flag.
• Users. Check Users for unfamiliar accounts, particularly with the Administrator role.
• Files. Look for .php files where they don't belong – in wp-content/uploads/ or left behind in wp-content/upgrade/ – and for recently modified core files.
• Behaviour. Unknown plugins, unexpected redirects for visitors, or new scheduled tasks.

Paste suspicious log lines into our IOC extractor to pull out the source IP addresses as a clean list for blocking or further checks. It runs entirely in your browser.

CISA also requires US federal agencies to carry out a forensic triage for this flaw, which is a good hint that patching alone isn't the end of the job if you were exposed.

What to do

1. Check your version under Dashboard → Updates.

2. Back up files and database first. Most hosting control panels let you download a backup.

3. Update with Update now. If automatic updates are on, confirm that the update actually completed.

4. Block web access to wp-content/upgrade/. Patchstack recommends denying it at the web server and making sure the folder can't be listed. WordPress keeps writing to the folder through the file system, so this doesn't break updates. On nginx:

   location ^~ /wp-content/upgrade/ {
       deny all;
   }

   On Apache, put a .htaccess file in wp-content/upgrade/ containing Require all denied. If you're on shared hosting, ask your host to do it.

5. Run the compromise checks above, especially if your site updated between 28 October and the day you patched.

6. If you find signs of compromise, change the passwords for WordPress admins, the database and FTP/SSH (our password generator creates strong ones), remove unknown accounts and files, and involve your host. If personal data such as customer records may have leaked, check your data protection obligations. In the US you can report incidents to CISA; in the UK, to the NCSC.

Timeline