WordPress 7.1.4 security release: site checklist

WordPress 7.1.4 came out on 28 October 2026. It’s a security release, and WordPress.org recommends updating immediately. If your site uses automatic background updates, the update may already have started on its own. May have. That’s the part I’d check before doing anything else.

Update, 30 Oct: attackers have started probing for the upgrade-folder flaw. Details in the new section below.

There’s also a server setting worth checking: whether visitors can reach wp-content/upgrade/ through a browser. One of the fixes concerns what happens in that folder during an update. I’ll keep the technical bit short, then walk through what I’d do on a small business site today.

What this release fixes

Patchstack counts 22 vulnerabilities across 17 advisories in 7.1.4. That’s a lot for one release; 7.1.3, three weeks earlier, addressed seven. The numbers sound alarming, but they don’t mean 22 strangers can break into your site from the street.

For all but two of these issues, a person needs an account with Contributor access or higher first. Put plainly, someone who can write posts could hide script in content that runs when an admin or visitor opens it. Seven advisories involve stored XSS bugs in the Interactivity API, where certain data-* attributes could get past the content filter. Other fixes cover block markup, the Customizer, comment pagination blocks, an Author-level upload issue and permissions for Notes on custom roles.

The writing-related bugs are a reason to review who still has an account, not a reason to stop publishing posts.
One smaller issue let anonymous visitors discover unpublished Customizer changesets. Access now requires the customize capability.
The release also updates root certificates after the eMudhra revocation.

Neither Patchstack nor the WordPress.org release post reports attacks in the wild. That’s different from saying nobody ever tried. I wouldn’t make that leap.

Why the upgrade folder gets special attention

The issue I’d tackle at the server level is a race condition in WordPress’s core upgrade process, reported by Umut Bayram. It needs no account. When WordPress installs or updates something, it extracts the package into wp-content/upgrade/. Your web server can serve that folder like other folders on the site.

Before 7.1.4, the temporary folder name was predictable from the package name. Cleanup could also remove the index.php file that prevents a directory listing. For a few seconds during an update, a complete WordPress copy could sit at a guessable, browsable location, including wp-admin/setup-config.php. That copy runs without the site’s usual configuration; reaching it at the right moment could let someone run an installer against a database they control, inside your site’s folder.

That timing is tight. Patchstack calls the issue high complexity and says it would not call it practical to exploit. Still, the window comes back with each update, including unattended ones, and the underlying weak spot dates back to WordPress 2.8. No login or interaction is needed. I wouldn’t ignore it just because the window is short.

Update, 30 Oct: attacks have started

A day after the release, Wordfence reported that attackers are already trying to exploit the upgrade-window flaw. Their first firewall match came nine minutes after they deployed the rule. In the first 21 hours they counted more than 18,500 requests aimed at the staged setup-config.php installer paths.

The pattern is what you’d expect from a race: some sources kept polling small groups of sites for about 14.5 hours, hoping to hit the few seconds while an update is running. Others tried many folder name and version variations. Not every request used the exact vulnerable path, and no source we read reports a confirmed compromise yet.

So the advice doesn’t change, it just got more urgent:

Confirm the site really runs 7.1.4 (or the patched release for your branch) under Dashboard > Updates.
Block web access to wp-content/upgrade/ as shown below.
If the site stayed unpatched, look for requests to PHP files under wp-content/upgrade, new admin users, unknown plugins or PHP files you didn’t put there.

If you use Wordfence: the exploit calls a PHP file directly without loading WordPress, so Wordfence says its firewall needs Extended Protection for this one. A firewall rule doesn’t replace the update.

What WordPress changed

Version 7.1.4 adds 16 random characters to the temporary folder name. It also recreates index.php and stops deleting it, and prevents wp-config.php from being copied out of the working folder. Those are fixes in WordPress itself.

Older branches received backports down to 4.7, according to Patchstack’s release list, including 7.0.8 and 4.7.39. The WordPress.org post said backports were in progress and would ship as they became ready, so check the latest available update for your branch rather than guessing from a version number. Sites on 4.6 or older get no backport. And only the newest WordPress version is actively supported; a backport isn’t a good reason to stay on an old branch indefinitely. WordPress 7.2 is planned for 8 December.

Do this today

Confirm the update landed. Don’t assume automatic updates definitly finished. Open Dashboard > Updates and check for “You have the latest version of WordPress.” You can also look at the version in the admin footer or at Tools > Site Health > Info > WordPress. If someone on your team uses WP-CLI, wp core version gives them a quick answer. On an older branch, look for that branch’s newest security backport, such as 7.0.8 on 7.0, rather than expecting to see 7.1.4.
Block web access to the upgrade folder. This works even while an update is running. A PHP firewall or security plugin can’t reliably cover this issue: the extracted copy loads its own WordPress files, so your site’s firewall doesn’t run for that request. On Apache, put this in the main .htaccess in your site root, above the WordPress block. Don’t put it inside wp-content/upgrade/; WordPress cleans that folder.
```
RedirectMatch 403 ^/wp-content/upgrade/
```
On Nginx, the server configuration needs this inside the server block:
```
location ^~ /wp-content/upgrade/ {
    deny all;
}
```
Then open https://yoursite/wp-content/upgrade/ in a browser. You want 403 Forbidden, not a file list. Between updates, the folder should hold nothing but index.php. Updates can still work because WordPress writes there through PHP, not through a visitor’s browser request. Can’t edit server config on managed hosting? Ask your host to block the path and confirm the result. With our web hosting, we handle that server configuration.
Review who can write. Go to Users > All Users and filter by Contributor, Author, Editor and any shop roles such as Shop manager. Remove ex-staff, old freelancers and agency accounts nobody uses. Downgrade access where the person still needs an account but no longer needs to publish. Fewer writers means fewer accounts that could expose the writing-related bugs. If you’re bringing in outside help, our guide to giving a developer access without losing control is a useful next read.
Keep updates on someone’s calendar. Automatic updates help, but somebody still needs to notice if one fails and check the site afterward. That’s part of our WordPress maintenance work if you’d rather hand it over. While you’re reviewing access, don’t forget old connections: audit application passwords and connection keys too. Removing a former writer’s login doesn’t by itself tell you what other access is still hanging around.

Start with the check you can verify

I’d start at Dashboard > Updates, then test the upgrade-folder address. Both checks give you an answer you can act on today. If the folder doesn’t return 403, ask whoever manages your server to fix that before you cross it off the list.

WordPress 7.1.4 security release: what to check on your site