WordPress 7.1.4: what site owners need to check after the 22-vulnerability security release

Do I need to update to WordPress 7.1.4 right now?

Yes. WordPress 7.1.4, released on October 28, 2026, is a security release that fixes 22 vulnerabilities, including one that can let an attacker run code on your server, without logging in, during the few seconds an update is running. CISA listed that vulnerability as actively exploited on November 3. Most sites update themselves within hours, but check yours today: confirm it shows 7.1.4 (or the fixed version for its branch, listed below), and make sure the folder WordPress uses for updates, wp-content/upgrade/, can’t be reached from the web.

Last updated November 4, 2026, 10:23 am Toronto time. New developments go at the top of the timeline below.

What happened with WordPress 7.1.4, and when?

WordPress shipped the fixes for every supported branch at once. Wordfence has since reported attackers trying the update vulnerability, and CISA now lists it as actively exploited. CISA gave no details, and I have not found a report naming a site that was broken into. Here is the order of events, newest first. Times are Toronto time, with UTC in brackets.

What was fixed in WordPress 7.1.4?

One serious vulnerability that needs no login, and a long list of smaller ones that need a logged-in account. Grouped by who could use them:

• Anyone, without logging in: the update race condition described above, which could lead to remote code execution, and unpublished Customizer changesets that visitors could find. A changeset is a set of design changes saved in the Customizer but not yet published.
• Contributors and authors: about a dozen stored cross-site scripting (XSS) vulnerabilities, where someone saves code in a post that runs later in the browser of an editor or administrator who opens it. They sit in block markup, the Interactivity API, the Customizer’s live preview, the Categories block, the Playlist and Image blocks, and the comment pagination and post navigation blocks. One Interactivity API issue could also freeze the browser of whoever opens the post.
• Editors and site setups with custom roles: stored XSS on the screen for personal data erasure requests, usernames shown unescaped on multisite network screens, and Notes, the block editor’s comments for collaborators, readable by users who can’t edit the post.
• Not a vulnerability: an update to the root certificates WordPress bundles, after a certificate authority’s certificates were revoked.

To close the update hole, according to Patchstack, 7.1.4 adds 16 random characters to the name of the folder each update unpacks into, so the path can’t be guessed. It also keeps the blank index.php in wp-content/upgrade/ instead of deleting it, so the folder can’t be listed, and it never copies wp-config.php out of an update’s working folder.

How do I check that my site has the fix?

Look at the version number WordPress reports, and match it to the fixed version for your branch. Go to Dashboard, Updates, or run wp core version with WP-CLI. If you are on the current branch, you want 7.1.4. If your site is on an older branch, it is fixed at these versions, from the version page:

If your site has not updated yet, find out why. Go to Tools, Site Health and look for a warning about background updates. The usual causes are a WP_AUTO_UPDATE_CORE or AUTOMATIC_UPDATER_DISABLED line in wp-config.php, a plugin that turns updates off, or a host that runs updates on its own schedule. On managed WordPress hosting, ask your host when it will apply 7.1.4. Otherwise, run the update from Dashboard, Updates, or with wp core update, and check the version again.

A site on an old branch is fixed by its backport, but it is still on a version WordPress no longer supports. If it is on 6.x or older, take this as the push to plan the move to 7.1, tested on a staging copy first.

How do I check that wp-content/upgrade/ is not reachable from the web?

Request the folder from outside and see what comes back. WordPress writes to this folder through PHP and the file system, never through the browser, so nobody needs to reach it over the web. Blocking it costs you nothing and covers the next update vulnerability of this kind too.

1. Open https://yoursite.com/wp-content/upgrade/ in a private browser window, or run curl -I https://yoursite.com/wp-content/upgrade/. A list of files is the bad result: fix it today. A blank page means the index.php is doing its job, which is what 7.1.4 restores. A 403 Forbidden means the folder is already blocked. A 404 usually means the folder doesn’t exist right now, which tells you nothing about what happens during the next update.
2. Add a rule at the web server that refuses every request for the folder, using one of the snippets below.
3. Run the same check again, plus curl -I https://yoursite.com/wp-content/upgrade/index.php. Both should now return 403 Forbidden.
4. Run a plugin or theme update, or wait for the next automatic one, and confirm it still works. It should, because the rule only affects web requests.

On Apache or LiteSpeed, put this in the .htaccess file in your WordPress folder, above the # BEGIN WordPress line. Don’t put an .htaccess file inside wp-content/upgrade/ itself: WordPress empties that folder when it cleans up after an update.

# Block web access to the folders WordPress uses during updates
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade(-temp-backup)?/ - [F,L]
</IfModule>

On nginx, add this inside your site’s server block, then test the configuration with nginx -t and reload nginx. The ^~ stops nginx from passing a request for a .php file in that folder to your PHP location first.

# Block web access to the folders WordPress uses during updates
location ^~ /wp-content/upgrade {
    deny all;
}

Both rules also cover wp-content/upgrade-temp-backup/, where WordPress keeps a copy of a plugin or theme while it updates it. If WordPress lives in a subfolder, add the subfolder to the path in the nginx rule. On managed hosting where you can’t edit the server configuration, ask your host whether it blocks wp-content/upgrade/; many do. Behind Cloudflare or another CDN, you can add a firewall rule that blocks the path, but keep the server rule too, in case someone reaches your server directly.

Look in your access logs for requests to PHP files under wp-content/upgrade/, and check for administrator accounts, plugins or PHP files you don’t recognise.

Should I review who can write posts on my site?

Yes, because most of the other fixes need an account with the Contributor role or higher. On a site where only you write, this takes a minute. On a site with guest authors, students or old freelancers, it matters more. Go to Users and filter by role, or list every account and its role with WP-CLI:

wp user list --fields=ID,user_login,roles,user_registered

Remove accounts nobody uses, and lower roles that are higher than the person needs. If someone you don’t trust had one of those accounts before your site updated, look at their recent drafts and posts before you or an editor opens them in the editor, since opening the post is what would have run the code.

What should plugin developers and 7.2 beta testers do?

Test anything that uses the Interactivity API on 7.1.4, and move beta sites to 7.2 Beta 3. Six of the 17 advisories are in the Interactivity API, covering bindings, event handlers, context and the router, and one more lets post content override Script Module data, so a fix may now refuse something a plugin used to get away with. Watch especially for javascript: URLs in bindings, values written into element IDs, and data passed through context. If a block stops working after the update, compare what it outputs on 7.1.3 and 7.1.4 before you assume the bug is in your code. Report a real regression on Trac.

If you test 7.2, Beta 3 is already out with all the fixes, so update your test sites now rather than waiting for November 3. Beta 3 also carries the new wp_kses() parser and the Secrets API, so if you are testing those, my post on the WP_SECRETS_KEY warning covers what to look for in Site Health.

The whole job comes down to two checks: the version number matches the table above, and a request for wp-content/upgrade/ gets a 403. If both are true, your site is covered. I will add anything new, such as CVE numbers or reports of attacks, to the timeline at the top.