Installing the WordPress security fix can still expose your site

A WordPress flaw that attackers are already using can still be used against a site during the very update that fixes it. The reason is simple. The update unpacks its files using the site's old, unpatched code. Umut Bayram, the Picus Security researcher who found the flaw, says an attacker who strikes at the right moment can run code on the server.

What happened

The flaw, tracked as CVE-2026-119977, affects WordPress 4.7 through 7.1.3. During a core update with a complete package, WordPress unpacks a copy of the new version into a temporary folder inside wp-content/upgrade. That copy includes the WordPress installer, and the web server can usually reach it. An attacker with no account who learns the folder's name can use the installer before WordPress deletes the copy and end up running code on the server.

WordPress fixed this last week in version 7.1.4, plus matching updates for older branches back to 4.7. The fix gives the temporary folder a random name. But the update that installs the fix still uses the old code. On sites running 5.9 or later, that code names the folder after the downloaded file, so the name can be guessed one last time.

Why it matters

The flaw is not just a theory. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its catalog of known exploited vulnerabilities this week. Wordfence, the security company that assigned the CVE identifier, saw attack attempts begin nine minutes after it deployed a firewall rule on release day. Some sources kept checking small groups of sites for about 14.5 hours, which fits attempts to catch a site mid-update.

Sites that update automatically are not spared. WordPress installs the fix the same way, using the same steps.

Who can relax a little

The window is short. Wordfence's lab tests found it lasted only seconds, and WordPress's own advisory rates the flaw low. Not every update exposes the installer either. Smaller partial packages expose a site only if they happen to contain the installer files. Once 7.1.4 or a branch fix is installed, later updates use a random folder name and are not affected this way.

What to do

The alert box above lists the steps. The key idea is to block web access to the upgrade folder before updating. WordPress works with that folder directly on disk, so blocking it does not break updates, the researcher says. The WP-CLI update command is not a shortcut, because it runs the same updater.

What happens next

Code described as an exploit has appeared in public GitHub repositories, but whether it works has not been established. WordPress 4.6 and earlier get no fix, so those sites need to move to a supported version. Wordfence also lists signs to check for on sites that stayed on an affected version after the release.