Installing a WordPress update can leave a site exposed to CVE-2026-119977 even as it installs the fix, according to security researcher Umut Bayram.
In a write-up published by Picus Security, he detailed a race condition in the core WordPress updater that can allow an unauthenticated attacker to take over a site. The flaw carries a CVSS score of 8.1 and affects WordPress 2.7.0 through 7.1.3. CISA added it to its Known Exploited Vulnerabilities catalog on Nov. 3, confirming active exploitation.
WordPress 7.1.4, released Oct. 28, fixed it, and WordPress is backporting the changes to every maintained branch down to 4.7. The flaw follows WP2Shell, a critical core flaw WordPress force-pushed a fix for in July.
How the Updater Exposes Sites, Even While Patching
During a core update, WordPress unpacks the new files into wp-content/upgrade, a temporary directory the web server can usually reach and where PHP files can run. The package includes WordPress’s setup installer, which requires no login and does not recognize that the live site is already configured.
On unpatched sites, an attacker who reaches it in time can point the temporary copy at a database they control and have that configuration copied over the live one. Bayram said the attacker can then create the first administrator account and, on a typical single-site installation, upload a plugin to run code on the server.
Exploitation also requires an update package containing the installer files and a temporary directory whose name the attacker can work out. Bayram said the name is predictable in versions 5.9.0 through 7.1.3 and 2.7.0 through 4.3.35, while versions 4.4.0 through 5.8.18 add a random suffix, so exposure there depends on the path leaking another way.
A core update runs code from two versions: the installed updater unpacks the package, then the new version copies files into place. During the update to 7.1.4, the new code stops an attacker’s configuration from replacing the live one, but the old updater still creates the predictable directory.
Bayram said an attacker can still set up that temporary copy with their own database, log in and run PHP with the web server’s privileges before cleanup, and from there read or write files in the live site. Only updates made after 7.1.4 is installed use a random directory name.
Block Web Access Before Updating
Bayram recommended blocking web access to wp-content/upgrade before updating and confirming that requests to it return a 403 error.
WordPress does not need to serve the directory over the web, so the block does not interrupt updates. He warned against placing an .htaccess file inside the folder, because the old updater empties it before unpacking.
His alternative was a manual update outside the web root, after backing up site files and the database, leaving the live configuration and wp-content untouched. He noted that WP-CLI’s core update command is not a substitute, because it uses the same updater.
Versions 2.7 through 4.6 received no fix, and Bayram said sites running them should move to a supported release.
