Title: WordPress Updater Race Condition (CVE-2026-119977): Fix First, Then Update — Or Check wp-content/upgrade
Summary:
WordPress fixed CVE-2026-119977, a race condition in the core updater now listed by CISA in its Known Exploited Vulnerabilities catalog on the basis of evidence of active exploitation (per Wordfence, who assigned the CVE and lists CVSS 8.1; WordPress’s own advisory record rates the issue Low). When a core update pulls the full package, the updater unpacks the new files beneath a predictable subdirectory of wp-content/upgrade — a web-served area that also holds a WordPress installer copy — so an unauthenticated attacker who won the timing race could reach that installer and run code with the web server’s permissions — the GitHub advisory for GHSA-4w3m-c66w-69mg describes it as remote code execution. Affected releases run from 7.1.0–7.1.3 back to 4.7.0–4.7.38, with fixes in 7.1.4 and backports through 4.7.39 (the advisory was published October 29 and credits Picus Security researcher Umut Bayram, who found the issue traces back to WordPress 2.7 in 2008). The nasty part, and the reason to sequence the patch: patching alone is the catch: the fixing update runs on the site’s old, unfixed uploader code, which on 5.9+ still derives the temporary folder’s name from the downloaded file — an attacker hitting exactly that stretch can reach the installer one final time (Wordfence’s tests put the window in seconds). Picus’s recommendation is to block web access to wp-content/upgrade before updating — e.g. an nginx location block or Require all denied in Apache, or RedirectMatch 403 ^/wp-content/upgrade/ in the root .htaccess (not a .htaccess inside the folder itself, which the old updater deletes), verify the path returns 403, then update. A manual update outside the web root works too; WP-CLI’s wp core update is not a substitute, as it runs the same updater. Afterward, later updates use random folder names and no longer leak the installer. Attack activity is real: Wordfence saw attempts begin nine minutes after deploying a firewall rule on release day, with sustained probing consistent with attackers trying to catch sites mid-update; sites that stayed affected should check for unexpected PHP requests under wp-content/upgrade, unknown admin accounts, plugins no one had installed, and stray PHP files in that folder. WordPress 4.6 and earlier receive no fixes.
References: