NEWS

Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time

CVE-2026-119977 in WordPress core is exploited, and the update itself unpacks with old code. Block wp-content/upgrade and move to 7.1.4.

Dylan H.

News Desk

November 6, 2026
3 min read
Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time

Summary

A flaw in WordPress core, tracked as CVE-2026-119977, is being actively exploited, and Picus Security researcher Umut Bayram, who found it, warns that some sites can still be attacked while installing the fix. The update unpacks its files using the site's old, unpatched code, so an attacker who strikes at that moment can still win.

The flaw affects WordPress 4.7 through 7.1.3. It is fixed in 7.1.4, with matching fixes for older branches back to 4.7. CISA has added it to the KEV catalog. Wordfence scored it 8.1 on CVSS, while WordPress's own advisory rates it low.

How It Works

During a core update that uses a complete package, WordPress unpacks a copy of the new version, installer included, into a temporary folder under wp-content/upgrade. The web server can usually reach that folder. An unauthenticated attacker who guesses the folder name and reaches the installer before it is deleted can run PHP code on the server. Before the fix, an attacker could also get a malicious wp-config.php copied over the real one.

  • On sites running 5.9 or later, the old updater creates predictable folder names.
  • Sites on 4.4 through 5.8 get random characters added to the name, which hides the folder unless it leaks elsewhere.
  • Within-branch updates (for example 7.1.3 to 7.1.4) were offered as partial packages. Cross-branch moves (for example 7.0.7 to 7.1.4) were offered as complete packages. Partial packages expose a site only if they contain the installer files.

Bayram's point: what decides exposure is whether the updater already installed on the site has been fixed, not whether the package is partial or complete. The fixed updater copies files using the new code.

Wordfence reported attack attempts nine minutes after it deployed a firewall rule on release day.

What to Do

  1. Block web access to wp-content/upgrade first. For Nginx: location ^~ /wp-content/upgrade/ { deny all; }. For Apache, use Require all denied in a Directory block. If that is the only option, use RedirectMatch 403 ^/wp-content/upgrade/ in the root .htaccess.
  2. Do not put an .htaccess file inside the upgrade folder, because the old updater deletes the folder's contents.
  3. Confirm that requests to /wp-content/upgrade/ return 403.
  4. Update to 7.1.4 or the fixed release for your branch. The researcher says WP-CLI's wp core update does not avoid the issue. A manual update outside the web root does.
  5. WordPress 4.6 and earlier get no security fixes, and the researcher says the flaw dates back to 2.7. Upgrade those sites to a supported version.

Signs of Compromise

Per Wordfence, look for:

  • Unexpected requests to PHP files under wp-content/upgrade.
  • Unrecognized administrator accounts.
  • Unfamiliar plugins.
  • PHP files in wp-content/upgrade that were not placed there deliberately.

Sources

  • The Hacker News, "Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time" (November 6, 2026)