WordPress Fix for Exploited Flaw Can Briefly Expose Some Sites During Update

Some WordPress sites can still be attacked while they install the fix for an actively exploited flaw, according to Umut Bayram, the Picus Security researcher who found it. The update that installs the fix still unpacks files using the site's old, unpatched code, so an attacker who strikes at the right moment can run code on the server. The flaw is tracked as CVE-2026-119977 and affects WordPress 4.7 through 7.1.3.

Why the Update Window Matters

WordPress released the fix last week in 7.1.4 and matching updates back to 4.7. CISA added the flaw to its known exploited vulnerabilities catalog earlier this week. During a complete-package core update, WordPress unpacks a copy of the new version into a temporary folder inside wp-content/upgrade, including the installer, and the web server can usually reach it. An attacker with no account who can determine the folder name and access the installer before deletion can run code. The fix randomizes the folder name, but the update that installs it uses the old code. On 5.9 or later, that old code names the folder after the downloaded file, so the name can be predicted one last time. Before the fix, an attacker could use the installer to write a new wp-config.php into the temporary copy, and the update would then overwrite the real file with it; that part of the fix already works during the update that installs it, because WordPress moves the files into place with the new code. During the window, an attacker can set up the temporary copy with their own database, log in, and run PHP with the web server's permissions before deletion, then read or write live site files.

Who Is Exposed

Not every update exposes the installer. Complete packages always include it; a partial package exposes a site only if it contains the installer files. Automatic updates use the same updater. The Hacker News checked WordPress.org's update service today: within a branch, such as 7.1.3 to 7.1.4, it offered a partial package, including for automatic updates, while a move from an older branch, such as 7.0.7 to 7.1.4, came only as a complete package. On 4.4 through 5.8, old code adds random characters that hide the folder name unless leaked. Once 7.1.4 or a branch fix is installed, later updates use a random name, and a wp-config.php in the temporary copy is never copied over the real one. Bayram said partial exposure depends on package contents, and a site falls back to a complete package if checksums do not match or during a reinstall. The deciding factor is whether the installed updater is already fixed.

What Administrators Should Do

Bayram recommends blocking web access to wp-content/upgrade before updating. WordPress uses the folder on disk, so blocking web access does not break updates. On Nginx, add location ^~ /wp-content/upgrade/ { deny all; }. On Apache, add Require all denied in a directory block. In .htaccess, add RedirectMatch 403 ^/wp-content/upgrade/ above rewrite rules, but do not put .htaccess inside the folder because the old updater deletes it. Confirm a request returns 403. Update to 7.1.4 or the fixed release for the branch. A manual update outside the web root is another safe route. WP-CLI wp core update is no substitute. WordPress 4.6 and earlier get no security updates, and the flaw dates back to 2.7, released in 2008.

Exploitation and Checks

CISA based its catalog addition on evidence of active exploitation but did not describe the attacks. Wordfence, the WordPress security company that assigned the CVE identifier, saw attempts begin nine minutes after it deployed a firewall rule on release day; two of the busiest sources kept checking small groups of sites for about 14.5 hours, which the company says aligns with attempts to catch the moment a site updates. Its score in the CVE record is 8.1 out of 10 on the CVSS scale, while WordPress's own advisory rates the flaw low. Code that its authors describe as an exploit has appeared in public GitHub repositories, and one of them says it also works on sites that still use a predictable folder during complete-package updates; whether the code works has not been established. Check for unexpected PHP requests under wp-content/upgrade, administrator accounts no one recognizes, plugins no one installed, and PHP files there that no one put there.

Sources: The Hacker News