The fix for the WordPress core flaw we covered on 30 October has a catch: the update that installs it can leave a site exposed one last time. Umut Bayram of Picus Security, who found the flaw, says the updater unpacks the new version using the site’s old, unpatched code, so an attacker who strikes at the right moment during that update can still run code on the server. The flaw is tracked as CVE-2026-119977; CISA added it to its Known Exploited Vulnerabilities catalog earlier this week, per The Hacker News. Our earlier post covers the attacks Wordfence was blocking.
During a core update that uses a complete package, WordPress unpacks a copy of the new version, including its installer, into a folder under wp-content/upgrade that the web server can usually reach. The 7.1.4 fix gives that folder a random name, but on sites running 5.9 or later the old code that performs the update still names the folder after the downloaded file, so an attacker can predict it. Bayram’s write-up says an attacker who catches that window can set up the temporary copy with their own database, log in to it and run PHP code with the web server’s permissions before the copy is deleted.
Not every update is exposed. Complete packages always include the installer; a smaller partial package is exposed only if it happens to contain the installer files. The Hacker News checked WordPress.org’s update service and saw partial packages offered for in-branch updates such as 7.1.3 to 7.1.4, and only complete packages for moves from an older branch such as 7.0.7 to 7.1.4. On 4.4 through 5.8 the old code adds random characters to the folder name, which hides it unless the site leaks it, for example in an error message. WordPress’s own advisory page rates the issue Low and lists no CVE ID.
How to check if you’re affected
Affected versions are WordPress 4.7 through 7.1.3, per the WordPress advisory. Patched releases are 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34 and 4.7.39. Picus says WordPress 2.7 through 4.6 received no fix and should move to a supported version. Check which WordPress version your site is running before you update. Sites with automatic background updates enabled install the fix through the same updater and the same steps, per The Hacker News.
Picus describes two safe ways to update:
- Block web access to
wp-content/upgrade/first. WordPress reads and writes this folder through the filesystem, so denying HTTP access does not break updates. On Nginx:location ^~ /wp-content/upgrade/ { deny all; }. On Apache, useRequire all deniedfor that directory in the virtual host, or addRedirectMatch 403 ^/wp-content/upgrade/to the.htaccessfile in the WordPress root, above the rewrite block. Do not put an.htaccessfile insidewp-content/upgrade/itself, because the unpatched code deletes that folder’s contents before extracting. Confirm the folder returns 403 before you start the update. - Update manually outside the web root. Download and extract the release somewhere else, back up files and the database, then copy the core files over the site while leaving
wp-config.phpandwp-contentuntouched. Picus noteswp core updatein WP-CLI is not a substitute, because it uses the same updater and extracts intowp-content/upgrade/.
If you cannot patch immediately, Picus advises confirming that your security controls have prevention and detection rules for CVE-2026-119977 and actually block requests targeting setup-config.php under wp-content/upgrade/. Once 7.1.4 or a branch fix is installed, later updates use a random folder name, per The Hacker News.
Sources
- WordPress advisory GHSA-4w3m-c66w-69mg: A race condition during core updates that could lead to remote code execution
- Picus Security: CVE-2026-119977: When Updating WordPress Becomes the Vulnerability
- WordPress.org News: WordPress 7.1.4
- The Hacker News: Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time