WordPress 7.1.4: A Flaw in the Update Process, Plus a Long List of Stored XSS Fixes

WordPress 7.1.4 shipped on October 28, 2026, and it closes a remote code execution flaw in the core update process itself. The same release fixes a long list of stored cross-site scripting (XSS) bugs, most of which need a logged-in account to use.

This is the fourth WordPress security release in 41 days. We covered the previous one in our WordPress 7.1.3 post, which published on October 28, the day 7.1.4 came out. This post walks through what 7.1.4 fixes, which older branches got the same fixes, what the update-window flaw means for agencies, and what to check on client sites this week.

The short version: update every site to WordPress 7.1.4, or to the latest release on its older branch. Then confirm the update actually ran. The update flaw only opens while an update is in progress, but the window opens again on every update until the site is patched. If your web server lets visitors browse wp-content/upgrade/, close that off too.

What WordPress 7.1.4 fixes

According to the WordPress 7.1.4 release post by Aaron Jorbin, this is a security release, and WordPress recommends that you update your sites immediately. Aaron Jorbin and Nik Tsekouras led the release.

The release post lists 13 entries. The WordPress 7.1.4 version page on HelpHub breaks them down further. It says WordPress 7.0 and 6.9 were each affected by all 22 vulnerabilities fixed in this round.

The headline fix is the one in the update process. The release post describes it as a weakness that can lead to remote code execution during the upgrade window. HelpHub calls it a race condition during core updates. Umut Bayram reported it.

Most of the rest is stored XSS. Stored XSS means a user saves code into content, and it runs later in another user’s browser. If that other user is an administrator, the attacker can act with the admin’s session.

The fixes at a glance

This table pairs each release-post entry with the access level HelpHub gives for it. Where the version page does not state a level, the table says so.

Two of the XSS reports are credited to Anthropic. The WordPress security team’s two-month update on its Core Security Initiative explains why. WordPress enrolled in Anthropic’s OSS Scanner, which gives open source projects free security scans. The team says it has started fixing issues from the first scan results.

How the update-window flaw works

WordPress’s own pages keep the details short. The release post and HelpHub name the problem and the reporter. HelpHub lists class-wp-upgrader.php and update-core.php among the changed files, but it does not map each fix to a file.

Patchstack published a longer analysis of WordPress 7.1.4 on October 28. Patchstack is a security vendor, so treat its write-up as its own research. According to Patchstack:

• During a core update, WordPress unpacks the new version into a folder under wp-content/upgrade/. The web server can serve that folder like any other.
• Before 7.1.4, that folder had a predictable name, and the cleanup step removed the index.php file that blocks directory listing.
• For the few seconds an update runs, a full copy of WordPress sits at a guessable path. That copy includes the setup script, which can run without the site’s configuration.
• No account is needed, but the attacker has to hit that short window.
• 7.1.4 adds 16 random characters to the folder name and keeps the index.php file in place.

Patchstack rates the flaw hard to exploit. It also notes the window comes back on every update, including automatic ones. A firewall plugin does not help here, because the request goes to the unpacked copy, which does not load the site’s plugins.

WordPress’s posts do not say whether this flaw has been exploited. Some press coverage reports exploit attempts since the release. We could not confirm those reports at their original source, so we are not repeating the numbers.

Which WordPress versions are fixed

WordPress only actively supports the newest version. It still backports security fixes to older branches, and this round went all the way back to 4.7.

The 7.1.4 version page lists a fixed release for each branch. Branches back to 6.8 were affected by most or all of the 22 issues. Older branches were affected by fewer. HelpHub’s version page lists a fixed release for every branch from 7.0 back to 4.7, all dated October 28.

The release post, written on release day, said older-branch backports were in progress and would ship as they were ready. The security team’s update explains that releases now go out in two waves, with the most widely used versions first. Check the WordPress releases page for your branch before you assume a fix is out. WordPress 4.6 and earlier get no security fixes at all.

WordPress 7.2 is planned for December 8, according to the release post. WordPress 7.2 Beta 3 shipped with the applicable fixes. If you are testing the beta, as in our WordPress 7.2 Beta 1 checklist, move test sites to Beta 3.

Why WordPress 7.1.4 matters for agencies

Most of the XSS fixes in WordPress 7.1.4 need a Contributor, Author or Editor account. That sounds limiting, but many of our readers run sites with exactly those roles. Association blogs take posts from member authors. Universities hand Contributor accounts to student workers. Newsrooms and nonprofits bring in freelance writers.

On those sites, a single stolen or careless low-level account becomes a path to the administrator’s session. That is the same chain we described in our wp2shell post and our WordPress 7.1.1 Click2Shell post.

The update flaw matters for a different reason. It needs no account, and it targets the moment you are trying to fix things. An agency that updates 40 client sites in one sitting opens 40 short windows. Automatic updates open them on their own schedule.

The pace matters too. The security team’s update says WordPress has closed more than 50 Critical or High issues across seven core security releases since mid-July. It also reports more than 3,000 HackerOne reports so far this year. Expect more releases like this one, and plan for them.

What to check on every client site

1. Confirm the version. Every site should report WordPress 7.1.4 or its branch’s fixed release. In the dashboard, go to Updates. The release post says sites with automatic background updates will update on their own. Do not assume they did. On the command line, wp core version from WP-CLI prints the installed version.

2. Check older branches separately. A site pinned to 6.9 or 7.0 should show 6.9.11 or 7.0.8. If a site sits on an even older branch, it is due for a real upgrade plan.

3. Close off wp-content/upgrade/. Patchstack recommends denying web access to that folder at the server level and confirming it is not listable. Test that on staging first. Many managed hosts set rules like this for you, so ask your host before adding your own.

4. Review low-level accounts. List every Contributor, Author and Editor. Remove the ones nobody uses. Turn on two-factor login for the rest where you can.

5. Look for stored scripts. If you suspect a bad actor had a Contributor account, review recent drafts, comments and Customizer changes for odd markup.

6. Keep a clean backup. A backup taken after the update gives you a known-good point. Our WordPress backup security guide covers how to keep those backups safe.

If any of this vocabulary is new, our explainer on how to read a CVE covers the terms advisories use.

What we do not know yet

As of November 2, 2026, WordPress has not published a CVE ID for the update flaw in its own posts. Press coverage cites one, but we could not confirm it at the source.

We also do not know which managed hosts already block wp-content/upgrade/ at the platform level. That varies by host, so check yours.

Frequently Asked Questions