WordPress 7.1.4: 22 security fixes, including one in the updater itself

WordPress 7.1.4 came out on October 28, 2026, three weeks after 7.1.3. It's a security release, and WordPress recommends updating immediately. Its version documentation counts 22 vulnerabilities, more than any earlier release on the 7.1 branch.

The one to read first is in WordPress's own updater. While a core update is running, a weakness in how WordPress handles the files it has just unpacked could lead to remote code execution. Most of the others are stored cross-site scripting that starts from a Contributor account, and a large share of those sit in the Interactivity API, the code that powers interactive blocks like the Image lightbox and the Navigation block's mobile menu.

Fixes for 7.0, 6.9, 6.8, 6.7 and 6.6 shipped within a minute of 7.1.4. When we checked, a little over three hours later, nothing had shipped yet for 6.5 or older, although WordPress's documentation already lists their version numbers. If you're on one of those branches, read this section.

What shipped

The release was led by Aaron Jorbin and Nik Tsekouras. There are 14 commits between the 7.1.3 and 7.1.4 tags: eight security fixes, one commit that brings in five more security changes from the block editor's repository, an update to the bundled root certificates, a version bump for the Twenty Twenty theme (one of its scripts changed), and four version bumps and tags.

In WordPress's own repository, the security changes add 319 lines and remove 84 across 28 files, not counting tests. The Interactivity API's browser code is built from the separate Gutenberg repository, and its share is larger: one commit there adds 639 lines and removes 90 across 11 files. WordPress's documentation lists 32 files as revised.

The count depends on where you look. The announcement doesn't give a number and lists 12 items plus the certificate update, grouping several Interactivity API issues together. The version documentation says 22 vulnerabilities and lists them in 17 entries, some covering more than one issue. We use the documentation's breakdown below because it states the access each issue needs.

Two of the issues are credited to Anthropic and two to Rafie Muhammad of Awesome Motive. The rest came from Umut Bayram, Antonio Lorensius Silaban, rekter0, Anas cherni, Marcel Karlsson, AnC and DatNLQ of VietSunshine Cyber Security, and Ben Bidner, Alex Concha, Jon Surrell, Luis Herranz, Weston Ruter and Ramon of the WordPress security team.

When we checked on October 29, none of the 22 had a CVE or a GitHub security advisory. Neither do 7.1.3's seven, three weeks after that release, so don't wait for a severity score. What an attacker needs first is the better guide.

The updater: remote code execution during a core update

Reported by Umut Bayram. WordPress describes it as a race condition during core updates that could lead to remote code execution, and hasn't published more detail. The patch shows where the weakness was.

When WordPress updates itself, it downloads the new version, unpacks it into a folder inside wp-content/upgrade/ and copies the files into place from there. wp-content is served by your web server like the rest of the site, so while an update runs, that unpacked copy of WordPress can be reached from a browser. The folder was named after the download plus six random characters. On a server that lists the contents of folders without an index file, anyone could read that name.

The fix changes three things:

• The folder name now ends in 16 random characters.
• WordPress puts an empty index.php in wp-content/upgrade/, so a directory listing there shows nothing.
• The step that copies the new files into place no longer copies a wp-config.php from the unpacked folder. A comment in the patch says one "could have been written to the working directory".

We think that last change shows the shape of the attack: something gets written into the unpacked copy while the update runs, and the update then carries it into your live site. The window is only as long as the update. To use it, an attacker had to find the folder in time, so we think servers that list directory contents were the most exposed. Many hosts turn listing off.

Updating to 7.1.4 is safe to do now. WordPress runs the final copy step with the new version's code, so the wp-config.php check already applies to this update. The new folder name takes effect from your next update. Plugin and theme updates unpack into the same folder, so they get the new name and the index.php too.

No account needed: unpublished Customizer changes

Reported by Antonio Lorensius Silaban. When you change your site in the Customizer and save a draft or schedule it, WordPress keeps the changes in a changeset. A preview link carries the changeset's ID, and that ID is what lets someone see the preview.

When a preview request arrived without an ID, WordPress loaded the latest unpublished changeset anyway, so a logged-out visitor could see changes nobody had published. It now does that only for users who are allowed to customise the site. Anyone else gets a new, empty ID that matches nothing.

This matters most on sites that use the Customizer, which usually means a classic theme. If you've drafted changes there that shouldn't be public yet, such as a new menu, header text or custom CSS for a launch, they could be seen until you updated.

A Contributor account: stored cross-site scripting

Contributors can write posts and submit them for review, but they can't publish, and WordPress filters what they save so it can't carry script. Each of these got something past that filtering or past the code that displays it. Stored cross-site scripting runs in the browser of whoever views the content, and for a Contributor's draft that's usually the Editor or Administrator who opens it to review.

Block markup with unusual whitespace

Reported by Rafie Muhammad. Blocks are saved as HTML comments, such as <!-- wp:paragraph -->. WordPress reads that markup with two parsers, one in PHP on the server and one in JavaScript in the editor, and they didn't agree on which characters count as whitespace inside the comment. Both now accept only the five whitespace characters HTML itself recognises. When two parsers read the same content differently, a check made against one reading can miss what the other produces.

Customizer selective refresh

Reported by Rafie Muhammad. Selective refresh updates part of the Customizer preview without reloading the page. It found the part to update using a value that could be declared in post content, and passed it to jQuery, which builds HTML from any string that looks like HTML. It now only looks elements up, and widget containers are built from the theme's registered sidebar instead of from values in the page. Twenty Twenty's Customizer script had the same pattern, which is why that theme moves to version 3.3.

Comments Pagination and Post Navigation Link labels

Reported by Alex Concha. These blocks let you set your own label, such as "Older comments" or "Next post". The labels went into the page without escaping. They're escaped now.

The Interactivity API

The Interactivity API is how core blocks respond in the browser without reloading the page: the Image block's lightbox, the Navigation block's overlay menu, the Search block's expanding field, the File block, Query Loop pagination that stays on the page, and the Playlist block added in 7.1. It reads its instructions from data-wp- attributes in the page's HTML, and those attributes can be in post content. WordPress lists five Contributor-level issues here, and one commit hardens the browser side against all of them:

• javascript: links through bindings. Reported by Luis Herranz and several independent reporters. A binding sets an attribute, such as a link's address, from the block's state. A value starting with javascript: is now refused, checked the way browsers read URLs so that hidden tabs or line breaks inside the word don't get it through.
• Event handler bindings. Reported by Jon Surrell. The server already refused to bind attributes such as onclick. The browser code now refuses them too.
• Embedded object elements. Reported by rekter0. WordPress only allows an object element in post content after checking what it loads. A binding could change that afterwards and make it load an admin page. On an object, bindings are now limited to attributes that can't change what it loads, on the server and in the browser. For users who can't post unfiltered HTML, WordPress also strips a binding that targets any attribute whose value it restricts.
• Prototype pollution through context namespaces. Reported by rekter0. Names from the markup become property names in JavaScript, and names like __proto__ and constructor could reach into JavaScript's own objects. They're refused now, and the objects those names land in are built so there's nothing to reach.
• Cross-site scripting and denial of service through bindings. Reported by rekter0, Marcel Karlsson, Jon Surrell and Alex Concha. WordPress lists these together, and they're covered by the same hardening. Jon Surrell also reported a stored denial of service in the Interactivity API, which the announcement lists separately.

An Author account: uploaded text files and the Interactivity Router

Reported by Anas cherni. Authors can upload files. The Interactivity Router, which loads the next page of a Query Loop without a full reload, fetched pages and treated whatever came back as HTML. A text file in the Media Library could be fetched as if it were a page, and its contents would run in the visitor's browser. The router now only accepts a successful response from your own site that's served as an HTML page.

An Editor account: personal data requests

Reported by Anthropic. Tools, then Erase Personal Data, lists requests by email address, and the list showed the address without escaping. So did the export list. WordPress's documentation gives this as an Editor-level issue. The addresses are escaped now on both screens.

Custom roles: Notes on posts they can't edit

Reported by Ramon of the WordPress security team. Notes, added in 6.9, are editorial comments attached to blocks. The REST API let any user who can moderate comments edit or delete any note. On WordPress's default roles that's an Editor, who can edit every post anyway. The gap opens with a custom role that moderates comments but can't edit posts. WordPress says such a role could read, edit and delete notes on posts it couldn't edit. Notes now require edit access to the post they belong to.

Access not stated

WordPress doesn't give an access level for these. We describe what the patched code now does.

Usernames and display names

Reported by Anthropic. The announcement says specially crafted user logins can lead to stored cross-site scripting. The documentation calls it a hardening fix for the multisite Network Users screens. The patch reaches further than that: usernames and display names are now escaped on the Users screen, the network Users screen, the delete-user confirmations, the profile screen, multisite signup and the "Howdy" menu in the toolbar. WordPress hasn't said how a crafted login gets onto a site in the first place.

The Categories block dropdown label

Reported by Ben Bidner. When the Categories block shows as a dropdown, its label became part of a PHP format string, so a label containing format codes could pull other values into the wrong place. The label is now passed in as a value.

Image lightbox and Playlist markup

Reported by Ben Bidner, and described as hardening. The Image block's lightbox button and the Playlist block's player were inserted by a regular expression that reused the block's own markup in the replacement. Some character sequences in that markup have a special meaning in a replacement. Both are now inserted with WordPress's HTML API.

Post content shadowing script data

Reported by Weston Ruter. WordPress passes data to some scripts in a script element with a known ID. Post content containing an element with the same ID could take its place. The admin screen this affects, Connectors, now reads its data only from a script element.

Root certificates

Not a vulnerability. WordPress ships its own bundle of root certificates for the HTTPS connections it makes. This release adds four and removes five, following the revocation of eMudhra certificates.

"I'm not on WordPress 7.1. Am I patched?"

If you're on 6.6 or newer, yes, once you take the update for your branch. You don't need to move to 7.1.

If you're on 6.5 or older, not yet. WordPress says the backports "are in progress and will ship as they become ready". When we checked on October 29, about three hours after 7.1.4, GitHub had release tags for 7.0 down to 6.6 and none for 6.5 or older. WordPress's version API agreed: it offered 6.6.11 as the oldest patched version and still listed 6.5.13, 6.4.13 and the other older patches from 7.1.3 as current. The documentation page lists versions such as 6.5.14 as released, but that was written ahead of the release. We'll update this post when they ship.

The "Affected by" counts are WordPress's. The version API now marks 7.1.3, 7.0.7, 6.9.10, 6.8.11, 6.7.10 and 6.6.10 as insecure. WordPress also repeats that only the most recent version is actively supported, and that fixes for older branches are a courtesy.

Lower counts don't leave a hole

A branch with a lower count doesn't have the code the missing fixes change. We checked this against each backport commit that has shipped, which lists the changes it carries:

• 7.0 and 6.9 carry all 13 changes.
• 6.8 and 6.7 leave out the Notes fix. Notes arrived in 6.9.
• 6.6 also leaves out the Categories block fix. The dropdown label it changes first appears in 6.7.

We'll check the older branches the same way when their backports ship. Those branches still only get fixes as a courtesy, so plan the move off them.

What to do

1. Update now, or confirm it's happened. Sites that take minor updates automatically should have 7.1.4 or their branch's patch already. Check any site where a plugin or a wp-config.php constant turns those updates off.
2. Match the version to your branch. Dashboard, then Updates, shows what you're running. On 6.9, the patched version is 6.9.11.
3. On 6.5 or older, plan the move to a current release. There's no patch for your branch yet. Test the upgrade on a staging copy first.
4. Turn off directory listing if your server allows it. On Apache, that's Options -Indexes. If you're not sure, ask your host.
5. Don't open Contributor drafts until you've updated. Most of these fixes apply when a page is displayed, so once you're updated, content saved earlier is covered too.
6. Treat unpublished Customizer changes as seen, if they held anything you weren't ready to show.
7. Include staging and development copies. They run the same updater and the same blocks as the live site.

If you're on Wordify

Automated Safe Updates applies a security release as soon as it's out, instead of holding it for your update window. The signal comes from WordPress: its version API now marks 7.1.3 and the superseded patches on 7.0 to 6.6 as insecure, and that's what moves the update to the front of the queue. Sites with it switched on were patched within hours of the release.

Sites on older branches take their own branch's backport, so a site on 7.0 moves to 7.0.8 and a site on 6.9 moves to 6.9.11, with no major upgrade.

Before each update, Wordify takes a verified restore point. After it, Wordify loads the site and compares what comes back with what came back before. If that health check fails, the update is rolled back. Some sites always need a look by hand, and those land on your Tasks page.

Directory listing is off on Wordify servers, so the update folder's name can't be read from a listing.