Security Brief: WordPress Core Update Flaw CVE-2026-119977 Lets Attackers Run Code

Attackers are targeting a WordPress core updater flaw, CVE-2026-119977. Block web access to /wp-content/upgrade/ before you update to 7.1.4 or your branch's fixed release.

Back to Blog

Graphic illustrating the WordPress core update flaw CVE-2026-119977 with warning text about security risks.

A flaw in the WordPress core updater, CVE-2026-119977, lets an attacker with no account run code on the server while a core update is running on WordPress 4.7 through 7.1.3. Attackers are already trying to catch that window. Before you update, block web access to /wp-content/upgrade/, then update to 7.1.4 or the fixed release for your branch.

What happened

During a core update, WordPress unpacks a full copy of the new version, including its setup installer, into a temporary folder under wp-content/upgrade. On affected versions that folder name was predictable, and on many servers the web server can reach it. An attacker who reaches the installer in the seconds before WordPress deletes the copy can run PHP code on the server, according to Wordfence (via The Hacker News) and Umut Bayram, the Picus Security researcher who reported the flaw.

WordPress released 7.1.4 on October 28, 2026, and backported the fix to every branch down to 4.7, for example 7.0.8, 6.9.11 and 4.7.39. Versions 4.6 and earlier get no fix. The fix gives the temporary folder a random name, stops it from being listed, and never copies a wp-config.php file out of it.

There is a catch. The update that installs the fix is unpacked by the site's old, unfixed code, so that one update can still be attacked, Bayram says. Complete update packages always include the installer files. Partial packages expose a site only if they happen to contain them. Automatic background updates use the same updater.

Wordfence says attempts began nine minutes after it deployed a firewall rule on release day, and it blocked 62,969 attacks in 24 hours (via The Hacker News). CISA added the flaw to its Known Exploited Vulnerabilities catalog on November 3, 2026, without describing the attacks. Wordfence scores it 8.1 on CVSS; WordPress's own advisory rates it low.

Why it matters for website owners

A site on an affected version is exposed each time a core update runs, including unattended ones. An attacker who wins the race can read or write files in the live site. A security plugin cannot stop this, because the temporary copy does not load your plugins, so Patchstack says to block the folder at the web server. Prepare before your next update, this week.

What to check on your site

  • Block the folder first. On Nginx, add location ^~ /wp-content/upgrade/ { deny all; }. On Apache, add Require all denied for that folder in the virtual host. If you can only edit .htaccess, add RedirectMatch 403 ^/wp-content/upgrade/ to the root file, above the WordPress rules. Do not put an .htaccess file inside the upgrade folder, because the old updater deletes it.
  • Confirm, then update. Check that /wp-content/upgrade/ returns a 403 error, then update to 7.1.4 or your branch's fixed release. WP-CLI's wp core update is not safer, because it uses the same updater. A manual update done outside the web root is the other safe option.
  • Leave unsupported versions. Sites on 4.6 or earlier have no fix and should move to a supported version.
  • Look for signs of attack. If you stayed on an affected version after October 28, Wordfence suggests looking for unexpected requests to PHP files under wp-content/upgrade, unknown administrator accounts, plugins no one installed, and stray PHP files in wp-content/upgrade.
  • Check your public profile. The WordPress Stack Checker shows version and hardening signals visible from outside. It cannot prove whether this flaw was exploited on your server.
  • Scan for public compromise signs. The Site Compromise Checker looks for public signs of compromise. A clean result does not replace checking server logs and admin accounts.

Sources