"isn’t partial versus complete. It’s whether the updater already installed on the site has been fixed," Umut Bayram, the Picus Security researcher who found the bug, told The Hacker News on November 6.
CVE-2026-119977 and which WordPress versions are affected
The flaw, tracked as CVE-2026-119977, affects WordPress 4.7 through 7.1.3. WordPress released the fix last week in version 7.1.4 and in matching updates for older branches back to 4.7, all listed in its security advisory. WordPress 4.6 and earlier no longer receive security updates and therefore have no fix available.
How the update process can open a last-second attack window
Bayram found that the update process itself can briefly expose some sites. When WordPress installs a core update that uses a complete package, it unpacks a copy of the new release into a temporary folder inside wp-content/upgrade. That copy includes the WordPress installer and is usually reachable by the web server. Because the update that installs the fix still unpacks its files using the site's existing, unpatched updater code, an attacker who can determine the temporary folder’s name and access the installer before WordPress deletes the copy can run PHP code on the server.
The fix changes the updater so the temporary folder gets a random name and prevents wp-config.php in the temporary copy from overwriting the live configuration. The part of the fix that stops wp-config.php from being copied over already takes effect during the update that installs the fix, because WordPress copies files into place using the new code. Nonetheless, Bayram says an attacker who catches the narrow 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, allowing reading or writing files in the live site.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleWhen a site is exposed: complete vs. partial packages and updater state
Not every update unpacks a reachable installer. Complete packages always include the installer files and therefore create a reachable copy; a partial package includes only files changed between two releases and will expose a site only if it happens to contain the installer files. The Hacker News checked WordPress.org’s update service and found that for updates within a branch (for example, 7.1.3 to 7.1.4) the service offered a partial package, including for automatic updates, while a move from an older branch (for example, 7.0.7 to 7.1.4) offered only complete packages.
Bayram emphasized the practical deciding factor: whether the updater already installed on the site has been fixed. WordPress also falls back to a complete package if a site's core files do not match official checksums or if the update is a reinstall, which can change exposure unexpectedly.
Observed exploitation activity and scoring
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-119977 to its catalog of known exploited vulnerabilities earlier this week; CISA’s entry was based on evidence of active exploitation, though the agency did not describe the attacks. Wordfence, which assigned the CVE identifier, saw attack attempts begin nine minutes after it deployed a firewall rule on the day of the release. Two of the busiest sources kept checking small groups of sites for about 14.5 hours, behavior Wordfence says aligns with attempts to catch the moment a site updates. In Wordfence lab tests, the vulnerable window lasted only seconds. The CVE record lists a CVSS score of 8.1 out of 10; WordPress’s own advisory rates the flaw low. Code described as an exploit has appeared in public GitHub repositories since earlier this week; whether that public code works in the wild has not been established.
Mitigations: block wp-content/upgrade or update manually
Bayram’s primary recommendation is to stop the web server from serving the wp-content/upgrade folder before updating. WordPress works with that folder directly on disk, so blocking web access does not break updates. Specific options he gave include:
- Block the folder in the web server configuration. On Nginx, add: location ^~ /wp-content/upgrade/ {{ deny all; }}. On Apache, add Require all denied inside a <Directory> block for that folder in the virtual host configuration.
- If you can only edit .htaccess, add: RedirectMatch 403 ^/wp-content/upgrade/ to the .htaccess file in the WordPress root, above the WordPress rewrite rules.
- Do not put an .htaccess file inside wp-content/upgrade itself: the old updater deletes everything in that folder before unpacking an update, so such a file would be removed when needed.
- Confirm that a request to /wp-content/upgrade/ returns a 403 error, then update to 7.1.4 or to the fixed release for your branch.
Bayram also recommends a manual update done outside the web root as a safe alternative: 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, and run the WordPress database update. He cautioned that WP-CLI’s wp core update is not a substitute because it runs the same updater and uses the same temporary folder.
What this means for site administrators, automatic-update users, and defenders
Site administrators should confirm their sites are updated to 7.1.4 or the appropriate branch fix and should block web access to wp-content/upgrade while updating. Sites that rely on automatic background updates are not exempt: WordPress installs fixes automatically via the same updater and therefore follows the same steps that can expose a temporary installer. Defenders who run network or host-based detections should look for unexpected requests to PHP files under wp-content/upgrade, PHP files placed there by unknown actors, unknown administrator accounts, or plugins that no one installed, as suggested by Wordfence.
The immediate reality is blunt: installing the fix can, briefly and in narrow circumstances, create the very temporary installation an attacker needs to execute code. The upshot Bayram leaves administrators with is simple and actionable — prevent web access to wp-content/upgrade or update manually outside the web root — and the deciding variable remains whether the updater already present on each site has been patched.
