WordPress Upgrade-Folder Race Condition, No CVE (Patchstack Report)
WordPress 7.1.4 and its same-day backports, which fix this race condition, shipped on 2026-10-28, so blocking wp-content/upgrade/ at the web server now closes the window that the update itself reopens.
WordPress 7.1.4, released on 2026-10-28, fixes 22 vulnerabilities across 17 advisories; Patchstack says almost all of them need an account first, usually a Contributor. The exception, according to Patchstack, is a race condition in the core upgrade process: while any install or update runs, WordPress unpacks the package into wp-content/upgrade/ under a predictable folder name and first deletes the index.php that blocks directory listing, so for a few seconds a full WordPress copy sits at a guessable, browsable path. Patchstack says an attacker who requests its wp-admin/setup-config.php in that window could run the installer against a database they control inside the victim's document root, which Patchstack says could lead to remote code execution with no account and would not be visible to a PHP-level firewall, though Patchstack rates the attack complexity high (AC:H) and does not consider it practical to exploit. The window reopens on every update, including unattended ones, and the flawed code dates back to WordPress 2.8. The release also fixes an unauthenticated leak of unpublished Customizer changesets. Patchstack lists no CVE for these flaws, and no exploitation is reported.
Affected: WordPress 2.8 through 7.1.3 (fixed in 7.1.4 and same-day backports down to 4.7.39)
How to Test
Check the WordPress version under Dashboard → Updates or in wp-includes/version.php. Anything older than 7.1.4, or older than the latest backport on your branch, is affected. Request https://<site>/wp-content/upgrade/ from outside: it should return 403, or at worst an empty index.php page, and never a directory listing. Between updates the folder should hold only index.php. In access logs, look for requests to wp-content/upgrade/*/wp-admin/setup-config.php.
How to Patch
1. Update to WordPress 7.1.4, or to the same-day backport release for your branch, using Dashboard → Updates or WP-CLI (wp core update). 2. Before updating, add a web-server rule that blocks wp-content/upgrade/. For nginx: location ^~ /wp-content/upgrade/ { deny all; }. For Apache: 'Require all denied' in that directory. 3. Turn off directory listing for the site.