WordPress's upgrade-window flaw: partial updates carry no installer, full ones do

On 3 November 2026 CISA (the US government's cybersecurity agency) added CVE-2026-119977, a flaw in the WordPress core updater, to its Known Exploited Vulnerabilities catalog, the list of flaws it has evidence attackers use ¹. US federal agencies have until 6 November to act ². WordPress fixed the flaw on 28 October in 7.1.4 and in a release for every branch back to 4.7 ³⁴. The flaw is a race: while WordPress unpacks a full update package, a complete copy of WordPress, installer included, sits for a few seconds in a folder the web server can serve, and a stranger who requests that installer in time can point the copy at a database they own ⁴⁵⁷.

A CVE number is the public ID of one flaw. A race condition is a flaw that only works when an attacker's request lands between two steps of a program. A branch is a release line such as 7.1 or 6.8; a point release is a fix inside it.

The window opens only when the update is a full package. Today we asked WordPress.org's update API which package it serves for each starting version and opened each zip ¹⁴. The automatic point update inside a branch is a partial package of about 50 files with no installer in it. A jump between branches from the dashboard's Update now unpacks a complete copy, 3,338 files or more.

Four readers rate one flaw from Low to 8.1

Wordfence put a firewall rule out on 28 October at 20:30 UTC, about three hours after the release, and saw the first matching request nine minutes later; in the first 21 hours it counted more than 18,500 requests aimed at staged setup-config.php paths, two of them polling small groups of sites for about 14.5 hours ⁷. Wordfence Free users get that rule on 27 November 2026 ⁷. The GitHub advisory went up on 29 October and the CVE record on 31 October ⁴⁵.

The staged copy carries the installer; the fix hides the folder and blocks one promotion

In 7.1.3 the updater empties wp-content/upgrade/, index.php included, names a working folder after the package and unzips into it ⁹. A package downloaded from WordPress.org is saved under its own name plus six random characters, so the folder is wordpress-7.1.4- and six characters ¹⁰. On a server that lists folders, the name is in the listing: the cleanup deletes any index.php in that folder, and the package ships none ⁹. The staged copy's wp-admin/setup-config.php is the ordinary installer: it takes a database host, name, user and password from whoever posts them and writes a wp-config.php beside itself ⁴⁷. The CVE record calls the path predictable; Wordfence saw attackers try many folder and version name variations ⁵⁷.

The 7.1.4 code makes three changes ¹¹¹². The working folder gets 16 random characters on its name. wp-content/upgrade/ gets an index.php that the cleanup now keeps. And update-core.php skips any wp-config.php found in the working folder when it copies files into the site. The updater copies update-core.php from the new package into place before it runs the update ¹³, so the third guard is already in force on the update that brings a site to 7.1.4; the first two are not, because the unpacking runs under the old code.

The automatic point update carries no installer

Measured 4 November 2026: the API's offers for each version and the file list of each zip ¹⁴. The chooser in the code takes the partial package when the API offers one for the exact installed version and the core files pass their checksum check; otherwise it takes new-bundled when the update crosses a bundled-theme version, otherwise no-content, otherwise full ¹³. A site with an edited core file, common on a site that was hacked once, loses the partial route and unpacks the installer.

How long the window stays open depends on the server. Unpacking the full 7.1.4 package (37.2 MB, 3,782 files) with Python's zipfile took 0.82 seconds, median of 5 runs, and copying the files 0.98 seconds, measured 4 November 2026 on an Apple laptop. A shared host is slower by an amount we do not know. Wordfence's lab saw seconds ⁷.

A third of sites are on a branch older than 7.1

Every branch from 4.7 up has its own fixed point release ³⁴, and for each version we asked about (7.1.3, 7.1.2, 7.0.7, 7.0.6, 6.8.11 and 6.8.10) the automatic update inside the branch is a partial package ¹⁴. Sites on 4.6 and older, 0.96% in the same count, have no fix, and a jump to a fixed branch is a full package ⁷¹⁴¹⁵.

Block the folder, then update, then look

The updater reads and writes the folder through the file system, not over the web ⁹, so a web rule on it does not touch the update. nginx, inside the server block and before the PHP location:

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

Apache, in the site root's .htaccess, not inside the folder, which the updater empties ⁸⁹:

RedirectMatch 403 ^/wp-content/upgrade/

Check it:

curl -sI https://example.com/wp-content/upgrade/ | head -1

A 403 is the answer wanted. On a host where the server is out of reach, a rule at the firewall or CDN in front of the site that blocks the path does the same job, and the host's support can say whether the folder is already blocked. Then Dashboard › Updates, or wp core version, shows 7.1.4 or the branch's own fixed release ³.

If the site ran a full update after 28 October without the block, the marks of an attempt are in the web log and on disk ⁷:

grep 'wp-content/upgrade/.*setup-config.php' access.log
wp core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_registered
find . -name '*.php' -newermt 2026-10-28 -not -path './wp-content/cache/*'

A request to setup-config.php under the upgrade folder that got a 200 is the mark; the second step of the installer is a POST with database details. Wordfence lists the rest to look for: administrator accounts you did not make, plugins you did not install, PHP files you did not place ⁷.