WordPress 7.1.4 Fixes an Upgrade Race and Stored XSS

WordPress 7.1.4 fixes an upgrade race and stored XSS

Released on 28 October 2026, WordPress 7.1.4 is a short-cycle security release with 13 security fixes, and the release team recommends updating sites immediately. Read the WordPress.org release note here.

This is the fourth security release on the 7.1 branch in six weeks, after 7.1.1 on 17 September, WordPress 7.1.2 and its critical remote code execution fix on 22 September, and WordPress 7.1.3 and its seven security fixes on 6 October. Unlike 7.1.3, this one came with severity ratings. The day after the release, the WordPress security team published 11 advisories on GitHub covering most of the 13 items, rating one high, six medium and four low.

The ratings change the picture. The note leads with an upgrade flaw that can lead to remote code execution, but its advisory is rated low because an attacker would have to win a race against a core update while it runs. The fix rated high covers stored cross-site scripting and denial of service issues in the Interactivity API that any user with the Contributor role or above could plant in post content, and several medium-rated fixes start from the same place. The sites with the most to lose are the ones that let other people write posts.

How it works

The release note gives each fix a single line. The GitHub security advisories and the security commits merged into the 7.1 branch on 28 October fill in the mechanism. In plain English:

• A race during core updates (rated low). Reported by Umut Bayram. When WordPress installs a core update from a complete package, it unpacks the new files into a working folder inside wp-content/upgrade, which the web server can reach. That folder had a predictable name, so an unauthenticated attacker who won a race against the extraction could reach remote code execution. WordPress now adds 16 random characters to the folder name, puts a blank index.php in the upgrade folder so its contents cannot be listed, and never copies a wp-config.php from the working folder into the live site.
• Interactivity API bindings (rated high). The Interactivity API is the standard way blocks add front-end behaviour, and core blocks including Search, Query, Navigation and File use it. Its directives are attributes in the markup, and a binding directive sets an attribute's value when the page renders, after WordPress's HTML filter has checked what a Contributor or Author saved. A binding could therefore put back a value the filter would have refused. The advisory lists four routes to stored XSS or a denial of service, including a directive named __proto__. The filter now strips a binding wherever it restricts that attribute's value, and bindings on object elements are limited to attributes that cannot change what the element loads. A related medium-rated fix, reported by Weston Ruter, stops post content from replacing the data a Script Module reads by giving an element the same ID as the module's data script.
• Customizer selective refresh and changesets (both rated medium). Selective refresh updates part of the Customizer preview without a reload. A Contributor could store markup in post content that selective refresh treated as HTML, so a script ran in an Administrator's Customizer preview (reported by Rafie Muhammad). Placement IDs are now escaped and looked up only as CSS selectors. Separately, a visitor who was not logged in could load the newest unpublished changeset, the saved but unpublished set of Customizer changes, in a front-end preview without knowing its ID (reported by Antonio Lorensius Silaban). Only users who can customise the site now have it loaded automatically.
• Block output (rated medium). The Categories block passed a user-controlled string to sprintf() as its format string, which allowed XSS (reported by Ben Bidner). The Comments Pagination Next, Comments Pagination Previous and Post Navigation Link blocks printed their labels without escaping, so a Contributor could store script in them (Alex Concha). The Image and Playlist blocks built their markup with preg_replace() using block attributes in the replacement text, so sequences such as $1 in those values were expanded into the output. They now insert their markup a safer way, and the advisory describes this one as hardening.
• Block markup parsing. Reported by Rafie Muhammad, and the only reported vulnerability without an advisory at the time of writing. The block parser commits merged the same day make the PHP parser on the server and the JavaScript parser in the editor accept only HTML whitespace inside block delimiters, so the two can no longer read the same block markup in different ways.
• Admin screens (rated low). An Editor or above could create a personal data erasure request through XML-RPC with a script in its email field, which ran when an Administrator opened Tools > Erase Personal Data (reported by Anthropic). A custom role holding the moderate_comments capability, but without edit access to a post, could read, change and delete the notes on that post; no default role is affected (Ramon of the WordPress security team). The release note also lists crafted user logins as a stored XSS, but its advisory classes the fix as hardening: usernames were printed unescaped on the multisite Network Users screens, and since normal WordPress flows cannot store an unsafe username, exploiting it needs direct database access.
• Root certificates. WordPress ships its own list of trusted certificate authorities, which it uses to check the HTTPS connections it makes to other services. The bundle has been updated, adding four certificates and removing five, following the eMudhra revocation.

Examples / Use cases

A multi-author site is the clearest case: a magazine with freelance contributors, a school site where students draft posts, or a franchise network where each branch writes its own updates. The Contributor role lets people write without publishing, so their drafts go to an editor for review. Before 7.1.4, such a draft could carry an Interactivity API binding or a crafted navigation label, and stored cross-site scripting runs with the permissions of whoever's browser renders it. On these sites that is usually an Editor or Administrator opening the draft.

A brochure site with a single administrator has much less to worry about. The two fixes that matter there are the ones that need no login: the upgrade race, which only exists while a core update is unpacking, and the Customizer changeset leak.

That leak matters most to sites on a classic theme, where the Customizer is still where design changes are staged. An agency preparing a seasonal promotion or a rebrand might save it in the Customizer and leave it unpublished until launch day. Before 7.1.4, a visitor could load the newest unpublished changeset in a preview and see the launch early.

Sites that handle data protection requests through WordPress's built-in Erase Personal Data tool are the case for the erasure-request fix, although it needs an Editor account (or a compromised one) and XML-RPC to be reachable. Membership sites with a custom moderator role are the ones the notes fix is aimed at.

What this means for UK site owners

Most sites should already be on 7.1.4. Security releases install through automatic background updates by default. The cases that need a person are the familiar ones: WP_AUTO_UPDATE_CORE set to false, a host that applies core updates on its own schedule, a version pinned in Composer, or a permissions problem that has quietly stopped updates. Check the version under Dashboard > Updates. The release note said backports to older branches were still in progress, but the WordPress release archive lists 7.0.8, 6.9.11 and every branch down to 4.7.39 as released on 28 October.

Cyber Essentials gives UK businesses a firm date this time. The scheme's Requirements for IT Infrastructure v3.3, in effect since 27 April 2026, ask for updates to be installed within 14 days of release where they fix vulnerabilities the vendor describes as critical or high risk. They add that when one update fixes issues of differing severity and any of them is critical or high risk, the whole update must go on within 14 days. 7.1.4 includes the high-rated Interactivity API fix, so on that wording the window runs to 11 November 2026. Publicly available commercial web applications are in scope by default and bespoke components are not, so check with your certification body how your website is scoped.

The erasure-request flaw also touches data protection. It sat on the screen many WordPress sites use to act on the right to erasure under the UK GDPR, where a script in an Administrator's browser acts with full admin rights. If your team uses that tool, confirm the update has landed before working through pending requests, then check the list for any email field that contains markup rather than an address.

If nobody is checking the version number, the user list and the roles plugins have added, our WordPress maintenance packages cover tested core and plugin updates, daily backups and security monitoring for UK sites.

Practical considerations

Two changes may affect custom code. In content saved by someone without the unfiltered HTML capability, WordPress now strips Interactivity API bindings on attributes whose values its HTML filter restricts, and it ignores bindings on object elements beyond a short list of safe attributes, logging a developer notice when it does. A custom block or theme that relies on such bindings in post content may behave differently after the update, so test interactive blocks on a staging copy. The upgrade folder will also now hold an index.php and randomly named working folders during updates. That is expected, not a sign of compromise.

Most of these fixes begin with an account that can write posts, so review who holds Contributor, Author and Editor access, remove unused accounts, and check custom roles for capabilities such as moderate_comments they do not need, using the roles and capabilities documentation as the reference. Finally, the block markup item had no advisory at the time of writing and none of the 11 advisories carried a CVSS score, so fuller detail may still follow.

FAQ