On this page
WordPress 7.1.4, released Wednesday Oct 28, fixes 22 vulnerabilities, and one of them needs no account at all. While WordPress installs an update, it unpacks a full copy of WordPress into wp-content/upgrade/, a folder the web server serves like any other. Before 7.1.4, anyone who requested the right path during those few seconds could reach that copy's installer and, per the fix itself, plant a wp-config.php that the update would then copy over your real one. The window opens on every update, including the automatic background updates most sites rely on, and that includes the update that installs 7.1.4 itself.
The other 21 bugs need a logged-in user, mostly Contributor or above: stored XSS in the Interactivity API, the Customizer, several blocks and two admin screens, plus a leak of unpublished Customizer changesets to anonymous visitors. No CVE IDs or GitHub advisories had been published for this release when we checked at 2:50 PM ET, and nobody has reported exploitation.
How to fix
Update to WordPress 7.1.4 from Dashboard, Updates, or with WP-CLI:
wp core update
wp core version # must print 7.1.4, or the fixed release for your branch
wp core verify-checksumsStaying on an older branch? HelpHub lists fixed releases for every branch back to 4.7: 7.0.8, 6.9.11, 6.8.12, 6.7.11 and 6.6.11, then 6.5.14 down to 4.7.39. One caveat on timing. At 2:50 PM ET the packages for 7.0.8 through 6.6.11 were downloadable from wordpress.org, but 6.5.14, 6.4.14 and 4.7.39 still returned 404, and the release post says the backports "will ship as they become ready." Sites on 6.5 or older may wait a few hours for theirs. WordPress 4.6 and older get no fix.
Then block the upgrade folder at the web server, not in PHP. Patchstack points out that a PHP firewall plugin never runs for this request: the unpacked copy boots from its own files, so the site's plugins never load. Put the rule in the server config or the site root, not in a file inside wp-content/upgrade/, because the pre-7.1.4 upgrader deletes everything in that folder before it unpacks.
# nginx, inside the server block
location ^~ /wp-content/upgrade/ { deny all; }
# Apache, in the vhost or the root .htaccess (outside the # BEGIN WordPress block)
RedirectMatch 403 ^/wp-content/upgrade/If you update by hand, add that rule first and update second. The installed upgrader, not the new one, unpacks the 7.1.4 package, so today's update runs the old folder logic one last time.
Why the window matters on auto-updating sites
Most WordPress sites take minor security releases on their own, and the release post says the update "will begin automatically" for sites that support background updates. That is the right default, and it is also exactly when this bug is live: the background update unpacks into the same web-served folder with nobody watching. An attacker does not need to guess when you click Update. Release day is when a large share of all WordPress sites run the upgrader within hours of each other.
So "auto-updates are on" is not the same as "this site is fixed." Confirm it finished:
wp core version
wp option get auto_core_update_failed # should be empty; a value means the last background update failed
wp option get core_updater.lock # a stale value means an update is stuck or still running
ls -la wp-content/upgrade/ # after 7.1.4, expect only index.phpA .maintenance file left in the site root is another sign an update died halfway.
What 7.1.4 changes in the upgrader
The fix is in one commit touching two files, credited to Umut Bayram (umut3806) and others:
class-wp-upgrader.phpappends 16 random characters to the working folder name. Before, the name came from the package file, so a plugin or theme zip uploaded through the admin landed at a fully predictable path.- The cleanup that empties
wp-content/upgrade/before each unpack now keepsindex.phpand recreates it if missing. The old cleanup deleted it, so on servers with directory listing on, the folder name could be read straight off the index. update-core.phpaddswp-config.phpto the files it never copies out of the working directory. The code comment says why: awp-config.php"could have been written to the working directory." That is the takeover path. An attacker runs the unpacked copy'swp-admin/setup-config.php, which boots without your config, points it at a database they control, and the core update would carry that config into your live site.
Patchstack scored the issue with high attack complexity and says it would not call it practical to exploit, because the request has to land inside an update. Its write-up also notes the vulnerable code dates back to WordPress 2.8.
Check for leftovers
Outside an update, wp-content/upgrade/ should hold nothing but an index.php. Look for anything else, and for a config file that changed when you did not change it:
find wp-content/upgrade -type f -name '*.php' ! -path 'wp-content/upgrade/index.php' -ls
stat -c '%y %n' wp-config.php
grep -E "DB_HOST|DB_NAME|DB_USER" wp-config.php # confirm these point at your database
curl -s -o /dev/null -w '%{http_code}' https://example.com/wp-content/upgrade/ # expect 403 after the blockAlso search access logs for requests to /wp-content/upgrade/ that end in setup-config.php or install.php. Legitimate traffic has no reason to request either path. If wp-config.php points at a database host you do not recognize, treat the site as compromised.
The account-required bugs
Seven of the 17 advisories are Interactivity API bugs with one root cause, which Patchstack explains well: KSES, the filter that decides what HTML a user without unfiltered_html may save, allows any data-* attribute, and every Interactivity directive is a data-* attribute. A Contributor could write directives into a post that the browser runtime then acted on, including URL bindings, event handler bindings and __proto__ keys in context. The denial of service in that set hangs the visitor's browser tab, not your server.
The rest, from the HelpHub list:
- Unpublished Customizer changesets exposed to anonymous visitors. A preview request without a changeset UUID adopted the latest unpublished changeset, so a visitor could see a site redesign before launch. Setting values stayed protected.
- Stored XSS in Customizer selective refresh, the Categories block (format string injection), the Comments Pagination and Post Navigation Link block labels, and block delimiters that the PHP and JavaScript parsers read differently.
- Stored XSS on the personal data erasure requests screen (Editor and above) and unescaped usernames on multisite Network Users screens. Anthropic reported both.
- Notes on posts readable, editable and deletable by custom roles that hold
moderate_commentswithout edit access to the post. - Hardening of
preg_replace()in the Image and Playlist blocks, and updated root certificates after the eMudhra revocation.
Every one of these starts with an account. List who has one:
wp user list --role=contributor --fields=user_login,user_registered
wp user list --role=author --fields=user_login,user_registered
wp user list --role=editor --fields=user_login,user_registeredWho is not in scope
- Sites deployed by Composer or git with
DISALLOW_FILE_MODSset to true. They never run the in-place upgrader, so there is no upgrade window to hit. They still need the 7.1.4 code for the other fixes. - Servers that already deny web access to
wp-content/upgrade/. The race needs that folder reachable over HTTP. - Single-author sites with no Contributor, Author or Editor accounts are out of reach of the XSS bugs, which all need one of those roles.
- Default role setups for the Notes bug. Admins and editors hold both capabilities, so it matters only with custom roles or post types.
What this is not
This is not a remote takeover anyone can fire at will: the attacker has to request the right path during the seconds an update runs, and the upgrade folder has to be web-reachable. It is not on the CISA KEV list and has no reported exploitation. It is also unrelated to the two earlier core bugs we covered, the page-template LFI in CVE-2026-87902 fixed in 7.1.2 and the unauthenticated comment XSS in CVE-2026-93485 fixed in 7.1.1, though 7.1.4 is the fourth core security release since Sep 17. If you skipped one, this update carries the earlier fixes too.
What do people ask about WordPress 7.1.4?
Is WordPress 7.1.4 a security release?
Yes. It fixes 22 vulnerabilities across 17 advisories, and WordPress recommends updating immediately.
Does the upgrade race let anyone hack a WordPress site without logging in?
Only during the few seconds an update is running, and only if wp-content/upgrade/ is reachable over the web. In that window an unauthenticated attacker could reach the unpacked copy's installer. WordPress 7.1.4 randomizes the folder name, keeps an index.php in place and refuses to copy a wp-config.php from the working directory.
Is my site fixed if automatic updates are on?
Only once the background update has finished. Check that wp core version prints 7.1.4 or your branch's fixed release, and that the auto_core_update_failed option is empty.
Do the WordPress 7.1.4 fixes have CVE IDs?
None had been published at 2:50 PM ET on Oct 28, 2026. We will add them to this post when they appear.
Which older WordPress versions get the fix?
Fixed releases are listed for every branch back to 4.7, from 7.0.8 down to 4.7.39. WordPress 4.6 and older receive no security updates.
