Administrators installing the fix for CVE-2026-119977 should first restrict public access to WordPress’s temporary upgrade directory. Some updates still expose a brief attack window.
WordPress’s official advisory lists 7.1.4 as fixed, alongside branch releases including 7.0.8 and 6.9.11, with backports through 4.7.39. The October 28 release announcement recommends prompt updating. The point of the extra access control is to protect that transition, rather than postpone the patch.
Why the first update needs attention
Picus researcher Umut Bayram explains that installed code extracts the package before patched code copies it. The copy fix protects the live configuration, while old extraction can still expose a predictable installer.
The package must contain the required installer files, its staging path must be known, and attackers must reach it before cleanup. Partial packages require checking their actual contents.
Apply the boundary at the web server
For a standard installation at the domain root, the Nginx example below denies requests beneath the upgrade path. Its prefix location modifier prevents a generic regular-expression PHP handler from taking precedence when this is the longest matching prefix; deny all rejects every client.
location ^~ /wp-content/upgrade/ {
deny all;
}On Apache with mod_alias and permitted FileInfo overrides, this rule in the WordPress-root .htaccess returns HTTP 403 for matching paths. Place it above WordPress’s rewrite block.
RedirectMatch 403 ^/wp-content/upgrade/Adapt the URL prefix for subdirectory installations or a relocated content directory, and validate the active server configuration. Managed-hosting users can ask their provider to implement the equivalent restriction for the actual staging location.
Keep the rule outside wp-content/upgrade, which the old updater clears. Bayram recommends confirming HTTP 403 before updating; HTTP blocking preserves filesystem access.
For a useful verification, also establish that the restriction covers nested file requests. A forbidden directory listing on its own does not demonstrate that PHP below the directory cannot run. Check the installed WordPress version after the update completes.
Review activity if the site remained exposed
Wordfence reported repeated polling of staged installer paths after the release. That telemetry records exploitation attempts, not a count of successful takeovers. Its investigation guidance includes unexpected PHP requests beneath the upgrade folder, unfamiliar administrator accounts, unrecognized plugins and unexplained PHP files.
Wordfence also stresses that direct requests to staged PHP can bypass normal WordPress loading. Where its firewall is used, Extended Protection is relevant; a firewall rule still does not replace installing the security release.
