WordPress update vulnerability can expose sites during the fix

The Hacker News reports that installing the fix for a WordPress update vulnerability can briefly leave some sites reachable while the updater unpacks files using the site’s old, unpatched code. Umut Bayram, a researcher at Picus Security, found that the updater copies a new release into a temporary folder under wp-content/upgrade using the previously installed updater code, and an attacker who can determine that folder name and reach the installer can run code on the server.

How the WordPress update vulnerability works

The flaw is tracked as CVE-2026-119977 and affects WordPress versions 4.7 through 7.1.3, The Hacker News reports. WordPress released a fix in version 7.1.4 and matching updates for older branches back to 4.7, which change how the temporary folder is named and prevent a temporary wp-config.php from being copied over the live site after the update completes.

Bayram’s analysis shows the updater unpacks a copy of the new release into wp-content/upgrade before the updated updater code is in place. That temporary copy includes the WordPress installer and can be reachable by the web server. On sites where the old updater names the folder predictably, an unauthenticated attacker who can guess the folder name and reach the installer before WordPress deletes the copy can log into that temporary copy and run PHP code with the web server’s permissions. Bayram summarized the deciding factor this way: "isn’t partial versus complete. It’s whether the updater already installed on the site has been fixed."

Not every update exposes the installer. Complete packages always include the installer files. Partial packages may omit them, depending on which files changed between releases. WordPress falls back to a complete package if the site's core files do not match official checksums or if the update is a reinstall. On versions 4.4 through 5.8 the old updater adds random characters to the temporary folder name, which makes guessing harder. Once 7.1.4 or a branch fix is installed, later updates use a random folder name and the temporary wp-config.php can no longer overwrite the real one.

Evidence of active exploitation and who to watch

CISA added the flaw to its catalog of known exploited vulnerabilities, The Hacker News notes. Wordfence, the WordPress security firm that assigned the CVE, reported attack attempts shortly after the fix was released. In Wordfence’s timeline, attempts began nine minutes after it deployed a firewall rule, and two of the busiest sources repeatedly checked small groups of sites for about 14.5 hours, which Wordfence says aligns with attempts to hit a site at the exact moment it updates.

Wordfence’s lab tests found the exploitable window lasted only seconds. WordPress’s own advisory rates the flaw low. Meanwhile, exploit-like code has appeared in public GitHub repositories this week; one repository claims the code works against sites that still use a predictable folder during complete-package updates, though whether that code works in the wild has not been established.

What to do before you update

Do not rely on luck at update time. The researcher’s primary recommendation is to stop the web server from serving wp-content/upgrade before you update. WordPress reads and writes that folder directly on disk, so blocking web access does not stop updates from working. Options reported by The Hacker News include:

• Block the folder in the web server configuration. Example for Nginx:

• For Apache, add a block in the virtual host configuration with Require all denied, for example:

• If you can only edit .htaccess in the WordPress root, add this above the WordPress rewrite rules:

• Do not place an .htaccess file inside wp-content/upgrade itself. The old updater deletes everything in that folder before it unpacks an update, so an .htaccess file placed there would be removed before it is needed.

• Confirm a request to /wp-content/upgrade/ returns a 403 before you update.

An alternative safe route is a manual update done outside the web root. The steps reported are: back up files and database, unpack the new release in a folder the web server does not serve, copy core files into place without touching wp-config.php or wp-content, then run the WordPress database update. That method avoids creating a temporary installer that the web can reach.

Note that WP-CLI’s wp core update command runs the same updater and unpacks into the same folder, so it does not avoid this exposure.

After the update, what to check

If you updated after the release or suspect an attempted exploit, Wordfence suggests checking for these signs: unexpected requests to PHP files under wp-content/upgrade, administrator accounts you do not recognize, plugins you did not install, and PHP files in wp-content/upgrade that no one put there. Because the exploitable window can be short, evidence may be brief, but check logs around update time.

Sites still on unsupported releases should move to a supported version. The researcher says the flaw goes back to WordPress 2.7, and WordPress 4.6 and earlier no longer receive security updates.

If you want to start with a simple external check of your site, consider a free scan to see what is exposed and then follow the server-side steps above to block the temporary folder before updating. /security.html