Updating to WordPress 7.1.4 Opens One Last Window

The researcher who found the WordPress flaw now under active attack warns that the update fixing it still leaves one last window open. It matters for any site still running a version from 4.7 to 7.1.3. The fix is to block access to one folder before you click «Update Now».

What we know

The underlying flaw: according to WordPress's GitHub advisory (29 October), during a core update with the full package WordPress unpacked the new files into a predictable, web-reachable folder. An attacker with no account who hits that window could run code on the server. It was fixed in WordPress 7.1.4 and in one release per branch, down to 4.7.39.
Attacks are real: the US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw, CVE-2026-119977, to its Known Exploited Vulnerabilities catalog on 3 November.
What's new: Umut Bayram of Picus Security explains in his write-up (updated 5 November) that an update runs code from two versions. Unpacking is done by the updater already installed, which is the old one. So during the jump from a vulnerable release to the fixed one, the temporary folder is still predictable.
What can happen during that jump: according to the researcher, an attacker can no longer replace the site's configuration, because that part of the fix works from the start. But they could still run code on the server, with the site's permissions, while the update is in progress.
What he recommends: block web access to the wp-content/upgrade/ folder and confirm it returns a 403 error before updating; or update manually, unpacking the package outside the public web folder. He notes that WP-CLI's wp core update command does not avoid the problem, because it uses the same updater.
Severity ratings still differ: WordPress's advisory rates it Low; Wordfence scores it 8.1 out of 10.

What changes and what doesn't

The order of steps changes. Until now the advice was «update now». For a site that is still unpatched, it is now «close the folder, then update».
The fix doesn't. There is no new release: the fix is still 7.1.4 or your branch's fixed release.
After the jump, the risk drops. According to the researcher, once the fixed release is installed, later updates use a temporary folder with a random name.
What the source doesn't say: it does not cover background automatic updates and gives no figure for how long the window lasts.

What to do, depending on where you are

Check your version under Dashboard → Updates. If it already shows 7.1.4 or your branch's fixed release, the jump has happened: check for signs of intrusion using the steps in the related story below, especially if the site was updated by hand or late.
If it isn't up to date, don't click «Update Now» yet. Take a full backup first (files and database).
Close the folder. On shared hosting you can usually edit the .htaccess file in the WordPress root. The researcher suggests adding, above the WordPress rules block, the line `RedirectMatch 403 ^/wp-content/upgrade/`. His article also gives the rule for nginx and for the Apache configuration. Don't create an .htaccess inside the folder itself: the old updater empties it before unpacking.
Check it from your browser. Open yourdomain.com/wp-content/upgrade/. You should get a 403 error («Forbidden»). If you see anything else, the rule isn't working: don't update yet.
Update to 7.1.4 or your branch's fixed release. According to the researcher, WordPress never needs to serve that folder over the web, so the rule doesn't break future updates.
If you can't touch the server, ask your host in writing: «Do you block web access to wp-content/upgrade/ before updating WordPress? Which version is my site on, and when was it updated?».

Sources

Updates: if WordPress publishes an official measure for the jump to the fixed release, it will be added here with its link.