WordPress CVE-2026-119977: the 7.1.4 install is one last window

The package that installs the fix for CVE-2026-119977 is unpacked by the WordPress already on the server. Picus Security researcher Umut Bayram, who reported the flaw, told The Hacker News on November 6 that this matters on the way to 7.1.4. The release randomizes the temporary folder. The updater that creates that folder, on a site that does not yet have the fix, is still the old one. For a site on 5.9 through 7.1.3, that old updater still picks a name an outsider can arrive at. The dangerous minute is the install.

WordPress fixed the bug in 7.1.4 and in matching releases for branches back to 4.7. The affected range in the advisory is 4.7 through 7.1.3. CISA put the flaw on the Known Exploited Vulnerabilities catalog on November 3. A site that has been waiting out the week re-enters the window when it finally applies the patch.

The copy that still runs

A full core package includes the installer. WordPress expands it under the content tree, in the upgrade directory, and the web server can usually request that copy until cleanup removes it. Someone with no account who reaches the installer in that interval can run code as the web server and, from there, read and write the live site.

Bayram’s account separates two outcomes. The new files, once they are the ones doing the copy, already stop a configuration planted in the temporary tree from replacing the live configuration. That half of the fix is in effect during the install. The temporary copy itself is still there until WordPress deletes it. That is the half that remains open when the updater on disk has never been fixed.

On 4.4 through 5.8 the old updater already obscures the folder name, so it stays hidden unless the site leaks it. On 5.9 and later the name is still foreseeable during this install. That is the population this briefing is for. WordPress 4.6 and older are out of security support, so there is no branch fix to wait for. Bayram traces the behavior to WordPress 2.7 in 2008. Those sites need a supported release.

Which download still carries the installer

The Hacker News checked WordPress.org’s update service on November 6. A move inside one branch, such as 7.1.3 to 7.1.4, was offered as a partial package, including on the automatic-update path. A move from an older branch, such as 7.0.7 to 7.1.4, was offered only as a complete package. A complete package always carries the installer. A partial package carries it only when those files are part of the diff.

Same-day clarification from Bayram: the split that decides the window is whether the updater already installed on the site has been fixed, and whether this particular package contains the installer. A site whose core files no longer match official checksums, or a reinstall, is handed a complete package even when a partial exists. Automatic background updates use the same updater and the same steps. Treat every update that starts from an unfixed updater as if the temporary installer will be web-reachable, and close that path before you begin.

The published score is 8.1. WordPress’s own advisory rates the issue low. Lab timings described publicly are measured in seconds. Wordfence saw attempts start nine minutes after it shipped a firewall rule on release day, and two of the busiest sources kept checking small groups of sites for about fourteen and a half hours. A short window plus patient polling is how this bug is being used. Code described as an exploit has been posted in public since the catalog entry. This briefing does not link it and does not describe it.

What to do before the update

Stop the web server from serving the upgrade directory, wp-content/upgrade, before you start. WordPress reads and writes that directory on disk. The site keeps updating if visitors cannot fetch it. Put the refusal in the web server configuration, or in the rules file at the WordPress root. A rules file placed inside the upgrade directory is deleted when the updater empties that directory at the start of the job, which is the moment you needed the rule.

Request the directory and expect a refusal. Then install 7.1.4, or the fixed release for the branch you are on. Read the version from the dashboard or from the files on disk after the job finishes.

The other clean path is a manual update from a folder the web server does not serve. Back up files and the database, unpack the release outside the web root, copy core into place, and leave wp-config.php and wp-content alone. Run the database update after the files are in place. The project’s command-line updater is the same unpack path as the dashboard. It still builds the temporary copy in the upgrade directory.

After 7.1.4 or the branch fix is installed, later updates use a random folder name, and a configuration file inside the temporary copy is not written over the live one. Until that version is what the server is running, the install is the exposure.

When the version string is current, look for the residue Wordfence named: requests for PHP under the upgrade directory, administrator accounts nobody created, plugins nobody installed, and PHP files left in that directory. A managed host that updates plugins on its own still needs this core check. Shared hosting, agency fleets, and forgotten campaign sites use the same updater.

The October 28 release closed the bug for the next update. It does not close the update that installs it. Deny the directory, then patch.

This briefing relies on public reporting by The Hacker News and on Umut Bayram’s November 6 account. It does not include exploit procedures.