WordPress update can expose sites to code execution during the fix
WordPress sites can still be attacked while installing the fix for CVE-2026-119977, according to The Hacker News, which cited Umut Bayram of Picus Security. The flaw affects WordPress 4.7 through 7.1.3, and WordPress released the fix in version 7.1.4 and matching updates for older branches. The U.S. Cybersecurity and Infrastructure Security Agency added the vulnerability to its catalog of known exploited vulnerabilities earlier this week.
The exposure occurs because the updater uses the old, vulnerable code to unpack the replacement files. During a complete-package update, WordPress places a temporary copy inside wp-content/upgrade, where the web server can usually reach the installer. An unauthenticated attacker who determines the temporary folder's name and reaches the installer before WordPress deletes the copy can run code with the web server's permissions, Bayram said.
The attacker can configure the temporary copy to use an attacker-controlled database and log in to it before it disappears, according to Bayram's technical write-up. From there, the attacker can read or write files in the live WordPress site. Wordfence told The Hacker News that it saw attack attempts begin nine minutes after deploying a firewall rule for the flaw, with two busy sources checking groups of sites for about 14.5 hours.
Bayram recommends blocking web access to wp-content/upgrade before starting the update. The folder remains usable by WordPress on disk, so blocking requests to it does not break the update, he said. Administrators should configure the web server to deny access and verify that a request to /wp-content/upgrade/ returns HTTP 403. An alternative is a manual update performed outside the web root, without replacing wp-config.php or wp-content.
Administrators should then install WordPress 7.1.4 or the fixed release for their branch. WP-CLI does not avoid the exposure because it uses the same updater and temporary folder, according to the researcher. WordPress 4.6 and earlier no longer receive security updates, so the evidence provides no fix for those versions.
Sites that remained on an affected version should check for unexpected requests to PHP files under wp-content/upgrade, unfamiliar administrator accounts and PHP files in that directory that administrators did not place there, Wordfence suggested. The Hacker News reported that public repositories contain code described by its authors as an exploit, but whether that code works has not been established.