WordPress Fix Can Expose Sites During Its Own Update

Block first, then update. Updating WordPress to 7.1.4 (or the matching fix for your older branch) is still the right move for CVE-2026-119977. But The Hacker News reports that the update itself can expose some sites one last time, according to Umut Bayram, the Picus Security researcher who found the flaw.

What changed

The update that installs the fix unpacks its files using the site’s old, unpatched code, so the new protection only applies to later updates. The flaw affects WordPress 4.7 through 7.1.3. Per the report, an attacker with no account who catches that window can end up running code on the server. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog earlier this week, as covered in our earlier report.

Who is exposed during the update

• Complete update packages always include the installer files. A smaller partial package exposes a site only if it happens to contain them.
• Automatic background updates use the same updater, so they carry the same exposure.
• The Hacker News checked WordPress.org’s update service for several versions. Updates within a branch, such as 7.1.3 to 7.1.4, were offered as partial packages. A jump from an older branch, such as 7.0.7 to 7.1.4, was offered only as complete packages.

Once 7.1.4 or a branch fix is installed, later updates are not affected.

What to do before updating

1. Stop the web server from serving wp-content/upgrade at all. Bayram says WordPress works with that folder directly on disk, so blocking web access does not break updates.
2. 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.
3. If you can only edit .htaccess, add RedirectMatch 403 ^/wp-content/upgrade/ to the file in the WordPress root, above the WordPress rewrite rules.
4. Then run the update. Do not postpone it: the flaw is on KEV.

Priority call

Patch first: sites jumping from an older branch, since they get complete packages, and any fleet with auto-updates on. Push the folder block to the web server config before the fix lands, not after. It is cheap and removes the window entirely.

Deprioritize: sites already on 7.1.4 or a branch fix, and sites that only take partial packages within a branch. Confirm the block is in place, then move on to something else.

See the WordPress hub for related coverage.