WordPress 7.1.4 security release: what agencies should do today

Update, 31 October 2026: attacks are growing. Wordfence now reports nearly 59,000 blocked attempts in 24 hours against the temporary installer files in wp-content/upgrade/ (up from 18,500 in the first 21 hours). Still no confirmed break-ins. If a client site is not on 7.1.4 or its branch’s backport yet, update it today and close the upgrade folder at the server; do not wait until Monday.

WordPress 7.1.4 came out on 28 October 2026 as a security release. It fixes 22 vulnerabilities across 17 advisories, and the same fixes were backported to every supported branch down to 4.7.39. One of them is unusual: a flaw in the core update process itself that needs no login. It is hard to exploit, but attackers started probing for it within a day, and it is the one issue in this release that a plugin firewall cannot stop. Here is what that means for the client sites you maintain, and what to do today.

What is fixed

• Unauthenticated code execution during an update. Before 7.1.4 the folder WordPress extracts updates into, inside wp-content/upgrade/, had a predictable name, and the clean-up removed the index.php that blocks directory listing. An attacker who hits the few seconds while an update runs, on a site where that folder is reachable over the web, could run code. Patchstack rates the attack complexity as high and does not call exploitation practical. Because the extracted copy does not load your site’s plugins, a PHP-level firewall plugin cannot block this request.
• Stored XSS from Contributor accounts and up, mostly in the Interactivity API (7 of the 17 advisories) and in several core blocks.
• Customizer: unpublished changesets could be seen by visitors who are not logged in.

Who is affected

Every site on a version below 7.1.4 or below the matching backport (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 and so on, down to 4.7.39). Sites on 4.6 or older get no fix at all. The XSS issues matter most on sites where clients, writers or guest authors have Contributor accounts or higher.

Check a site in two minutes

1. Version: in wp-admin go to Dashboard → Updates, or run wp core version. Anything below 7.1.4 (or your branch’s backport) needs the update.
2. Upgrade folder: open https://example.com/wp-content/upgrade/ in a private window. A 403 or 404 is what you want. A file listing or an empty 200 page means the folder is reachable from the web.
3. Accounts: in Users, filter on Contributor, Author and Editor. Remove the ones nobody uses.

What to do now

1. Update core to 7.1.4 or the backport for your branch. Minor security releases normally install by themselves; check that they did, because hosts and some plugins switch automatic core updates off. Make sure you have a fresh backup first, and check the homepage, a form and the checkout after.
2. Block web access to the upgrade folder at the web server, not in a plugin. On Apache, a .htaccess file in wp-content/upgrade/ with Require all denied. On nginx, location ^~ /wp-content/upgrade/ { deny all; }. WordPress still writes to the folder through PHP, so updates keep working. On managed hosting where you cannot change the server, ask your host to do it.
3. Sites on 4.6 or older: plan the move to a supported version now. There will be no fix for them.

Attackers are probing for this flaw, but no successful break-ins have been confirmed, so an updated site with a closed upgrade folder needs no restore or key rotation because of this release alone. If you do see unknown files in wp-content/upgrade/ or new administrator accounts, treat it as a compromise: restore from a backup made before those files appeared, then change passwords and salts. Our vulnerability-day routine has the full steps.

How Verploy helps

Every update is checked. Risky ones tested on a copy first. WordPress core always counts as risky: it is tested on a private copy of the site before the live site changes, and if a check fails after going live, the site is rolled back automatically. Nightly encrypted backups in the EU give you a clean point to return to, and known vulnerabilities show up per site with a link to the source.

Source: Patchstack, “WordPress 7.1.4 Security Release”, 28 October 2026, patchstack.com. Wordfence exploitation warning, 29 October 2026, as reported by SecurityOnline; 24-hour figure as reported by CyberPress, 31 October 2026. Checked 31 October 2026.