A security release, not a routine update
The official WordPress 7.1.4 announcement is dated 28 October 2026 and presents it as a security release: it recommends updating immediately, and sites with automatic background updates will move on their own. According to Patchstack, WordPress counts 22 vulnerabilities across 17 advisories, against 7 for 7.1.3, released three weeks earlier. Seven of the seventeen advisories concern the Interactivity API, and most of the others are stored XSS issues that require at least a Contributor account. There is also an unpublished customizer changeset visible to an anonymous visitor, and a weakness in the update process itself. Neither the official announcement nor Patchstack reports any exploitation, and this article claims none.
The update race condition, and why not to wait
Before 7.1.4, the extraction folder created under wp-content/upgrade/ had a predictable name for packages uploaded from the admin, and the cleanup deleted everything in it, including the index.php file that blocks directory listing. During an update, a full copy of WordPress therefore sat at a guessable, browsable address, wp-admin/setup-config.php included. No account or user action is required, but the attacker must hit a window of a few seconds. Patchstack rates exploitation as difficult and impractical; the window nonetheless comes back on every update, automatic ones included. The fix appends 16 random characters to the folder name, recreates index.php without deleting it, and stops wp-config.php from being copied out of the working directory. The agency objection remains: if it is hard to exploit, why act now? Because the core update comes first and costs one command per site, and closing the folder at server level is defense in depth. A PHP application firewall cannot hold it, since the extracted copy runs without the site's mu-plugins.
Inventory, then update every site in the fleet
Eight WP-CLI steps, from checking to verifying
Back up first
Export each site's database, then copy
wp-contentif no file backup exists yet:wp db export pre-update.sqlFind the installs
On a server hosting several accounts, list the
wp-config.phpfiles:find /home -name wp-config.php -not -path '*/wp-content/*' 2>/dev/nullRead each site's version
For one site, then for a list of paths (one per line in
sites.txt):
`wp core version
wp core check-update`while read -r d; do printf '%s ' "$d"; wp --path="$d" core version --skip-plugins --skip-themes; done < sites.txtSpot branches without a fix
Compare each version to the table below: a 4.6 branch or older has no fix and drops out of the update round.
Update the core
To move to the latest version, run the first command; to stay on the installed branch and apply only its fix, run the second:
wp core updatewp core update --minorUpdate the database
Apply any schema migrations:
wp core update-dbVerify the result
Read the version again, then check the integrity of the core files:
`wp core version
wp core verify-checksums`Loop over the fleet
Replay the branch update on every path in the list:
while read -r d; do wp --path="$d" core update --minor && wp --path="$d" core update-db; done < sites.txt
Fixed version per branch, 28 October 2026
Scroll the table
| Installed branch | Fixed version | Agency action |
|---|---|---|
| 7.1 | 7.1.4 | Update; automatic core updates handle it if enabled |
| 7.0 | 7.0.8 | Minor update, then plan the branch upgrade |
| 6.9 | 6.9.11 | Minor update, then plan the branch upgrade |
| 6.8 | 6.8.12 | Minor update, then plan the branch upgrade |
| 6.7, 6.6, 6.5, 6.4 | 6.7.11, 6.6.11, 6.5.14, 6.4.14 | Minor update, then prioritise the branch upgrade |
| 6.3 to 4.7 | One fix per branch, down to 4.7.39 | Minor update, then migrate to a current branch |
| 4.6 and earlier | No fix | Do not patch: migrate the site |
The agency rule fits in one sentence: a site on a branch without a fix gets migrated, not patched. The official post states that fixes are backported to every eligible branch, currently through 4.7, and that they roll out as they become ready; confirm on wordpress.org which number is available for each branch before promising a date to the client. On responsibility, you are the one the client calls if a site goes down: record per site the version before, the version after and the time of the operation, and keep that log available to the client. For the PHP inventory of the same fleet, see the dedicated article; for an earlier core flaw, see the one on 7.1.2.
Closing wp-content/upgrade/ at server level
The source establishes one thing only: deny web access to wp-content/upgrade/ and confirm the folder is not listable; between two updates it should contain only index.php. The rules below are therefore generic hardening that we propose, not an instruction from the advisory. The update goes through PHP's filesystem rather than an HTTP request, so refusing web access does not get in its way. This block does not replace the core update: it closes the window during future operations. Always place the rule at site or server level, never inside the folder itself, which the update process manipulates.
Eight actions by environment, from blocking to proof
nginx: block the folder
Add it to the site's
serverblock, before the block that handles PHP files; the^~modifier stops a regular expression from taking precedence:
`location ^~ /wp-content/upgrade/ {
return 404;
}`
Then test and reload:nginx -t && systemctl reload nginxnginx: one rule for the whole fleet
Put the rule in a snippet file and include it in every vhost, so a new site receives it too:
include /etc/nginx/snippets/wp-upgrade-deny.conf;Apache: Directory block
In the vhost configuration, with the site's real path:
`<Directory "/var/www/your-domain.com/wp-content/upgrade">
Require all denied
</Directory>`
Then validate and reload:apachectl configtest && systemctl reload apache2Docker: where to put the rule
The rule goes in the container that serves HTTP: the nginx reverse proxy or the image's Apache configuration. Mount it as a volume so it survives a rebuild, then reload the container.
Prove it answers 403 or 404
Test the folder and its
index.phpfrom outside; each line must return 403 or 404, not 200:
`curl -I https://your-domain.com/wp-content/upgrade/
curl -I https://your-domain.com/wp-content/upgrade/index.php`Cover every vhost
List the sites that lack the rule; the list must be empty after a deployment:
grep -L -E 'wp-content/upgrade|wp-upgrade-deny' /etc/nginx/sites-enabled/*Check the folder contents
Outside an update in progress, only
index.phpshould appear:ls -A /var/www/your-domain.com/wp-content/upgrade
External authors: what Contributor XSS changes
Five checks on a client site's accounts
- List the accounts — spot Contributor roles and above:
wp user list --role=contributor --fields=ID,user_login,user_registered - Remove what is unused — delete or demote accounts of former contractors and departed writers.
- Do not open accounts for convenience — a stored XSS needs an account that writes; fewer accounts, less surface.
- Warn administrators — several flaws trigger when an administrator opens a booby-trapped item or the customizer screen.
- Update before reviewing — apply 7.1.4 before reopening external contributors' drafts.
A security release is mostly a test of method. If the inventory, the update and the server rule take a morning on ten sites, they will take three days on a hundred. An agency space centralises cPanel accounts, hosting plans and expirations, so the round starts from an up-to-date list rather than a search.
