WordPress Patch Race Condition: Updating to 7.1.4 Can Itself Open a Window for Exploitation

As reported by The Hacker News, researcher Umut Bayram of Picus Security has uncovered a deeply ironic twist in the WordPress CVE-2026-119977 patch story: the act of installing the fix can itself become the attack vector — one last time.

The root cause is architectural. WordPress's updater unpacks a complete copy of the new version into a predictable temporary directory under wp-content/upgrade/ using the site's existing (unpatched) code. On sites running WordPress 5.9 or later, that directory name is derived from the downloaded filename — meaning it is predictable. If an attacker can guess the folder name and reach the bundled installer before the update completes and the directory is deleted, they can spin up a rogue WordPress instance, point it at their own database, and execute arbitrary PHP code with web server permissions. From there, the live site's filesystem is accessible.

Vulnerability Details

Why This Matters

This finding exposes a class of problem that defenders rarely consider: the patching process itself as attack surface. The vulnerability creates a race condition where the remediation step and the exploitation window overlap. For organizations managing dozens or hundreds of WordPress instances — especially in hosting environments — the brief update window may be systematically scannable and exploitable at scale.

The exposure is not uniform. Complete package updates always include installer files. Partial packages, built for specific version transitions, may or may not contain them. Sites with automatic background updates are also affected, since the same updater handles those updates silently — meaning administrators may not even know the window occurred.

The fundamental issue is that WordPress unpacks new code using old code, creating a trust boundary gap where neither the pre-patch nor post-patch protections fully apply.

Broader Implications

Shield53 Recommendations

Immediate Actions

• Block web access to wp-content/upgrade/ before patching. Add a server-level rule (nginx location block, Apache .htaccess, or WAF policy) denying all external HTTP access to this directory. Keep the rule in place permanently.
• Disable automatic updates temporarily until you can apply the patch in a controlled window with the directory block in place.
• Update to WordPress 7.1.4 (or the appropriate backported release) as soon as the directory block is confirmed active.
• After updating, verify the patch is applied and re-enable automatic updates if desired.

Detection Guidance

• Monitor web server access logs for HTTP requests to wp-content/upgrade/ paths, especially install.php or wp-admin/install.php within that directory.
• Alert on any successful HTTP 200 responses to the upgrade directory during known update windows.
• Check for unexpected wp-config.php modifications or new database configuration files in the WordPress root.
• Review file integrity monitoring alerts for changes during the update window that fall outside expected WordPress core file replacements.

Server-Level Hardening (nginx example)

location ~ ^/wp-content/upgrade/ {
    deny all;
    return 403;
}

This rule should be considered a permanent hardening measure, not a temporary patch-time control. The upgrade directory should never be web-accessible under normal operation.

For Hosting Providers

Multi-tenant hosting providers should implement the directory block at the platform level rather than relying on individual site owners. Given that CISA has confirmed active exploitation, treat any unpatched WordPress instance in the 4.7–7.1.3 range as compromised-by-default and prioritize patching across all tenant environments with the directory block pre-applied.