WordPress 7.1.4 Fixes 12 Security Issues: Update Now

WordPress 7.1.4 came out on 28 October 2026, three weeks after 7.1.3. It is a security release, and the list is long: the official release post names 13 items. Twelve are fixes for vulnerabilities. The thirteenth updates the bundled list of root certificates after a certificate authority, eMudhra, was revoked. If your site is not on 7.1.4 yet, this post explains what it fixes, how to confirm the update actually landed, and what to check afterwards.

What the 12 fixes cover

The release post groups the problems into four kinds. You don’t need to understand the code behind each one, but the groups tell you where the risk sat.

• Remote code execution during upgrades. A weakness in the upgrade process could allow code to run during the short window while an upgrade is in progress. This is the most serious type of bug a web application can have, because it means running commands on your server.
• Stored cross-site scripting (XSS). Several separate issues, in block markup, privacy data removal requests, the Interactivity API, Customizer selective refresh, the Categories block, user logins, the Playlist and image blocks, and the comments pagination blocks. Stored XSS means a script can be saved into the site and then run in another person’s browser, often an administrator’s.
• Stored denial of service. One issue in the Interactivity API that could be used to make pages fail.
• Information exposure. Unpublished Customizer changesets could be found by visitors who were not logged in, and privileged users without edit access could read notes attached to posts.

The release post does not publish exploit details, and that is normal practice. The safe assumption is that once a fix is public, people compare the old and new code to work out how to attack sites that have not updated.

Check that the update actually landed

WordPress says that sites with automatic background updates will start updating on their own. That covers most sites, but “most” is not “yours”. In support work, one pattern comes up again and again: a site owner assumes auto-updates ran, and the site is still two minor versions behind because something quietly blocked them. Checking takes under a minute.

1. Log in and open Dashboard → Updates. The top of the page shows the version you are running. It should say 7.1.4.
2. If it shows an older version, click Update Now on the same page. The release post gives this as the manual route.
3. If the update fails, note the exact error message. A failed core update is usually a file permission or disk space problem on the server, and your host can tell you which.
4. Open Tools → Site Health and look at the Status tab. It reports whether background updates are working, which tells you whether the next security release will arrive on its own.

If you manage several sites, check each one. A site that missed 7.1.4 may also have missed 7.1.3, which fixed seven security issues of its own. The earlier post on what WordPress 7.1.3 fixed covers that release.

Why auto-updates sometimes don’t run

WordPress applies minor releases like 7.1.4 automatically by default. When a site does not update, the cause is usually one of these:

• A line in wp-config.php such as AUTOMATIC_UPDATER_DISABLED or a WP_AUTO_UPDATE_CORE setting that turns core updates off. A developer may have added it years ago and forgotten.
• The site is under version control, and WordPress detects this and skips updates on purpose.
• WP-Cron does not run, often because the site gets very little traffic or because DISABLE_WP_CRON is set without a real server cron job to replace it.
• File ownership on the server stops WordPress from writing its own files.

Each of these is a sensible choice in some setups. The problem is only when nobody knows the choice was made. If any of them apply to your site, someone has to apply security releases by hand, and that person should know it is their job.

After updating: three quick checks

A security release changes very little apart from the fixes, so breakage is rare. Still, the fixes touch blocks, the Customizer and the Interactivity API, which plugins and themes also use. After updating:

• Open a few pages that use blocks heavily, such as your home page and a long post, and look for layout changes.
• If your theme or plugins use the Interactivity API (for example, interactive filters or a search block), test those parts of the page.
• Review your user list under Users. Several of the XSS fixes concern content that logged-in users can create. Old accounts that nobody uses any more are a risk on any site, and removing them costs nothing.

A security release does not change SEO settings, so there is nothing to adjust in Rank Math or anywhere else. What matters for search is that the site stays clean. Google can show a “This site may be hacked” warning next to a compromised site in its results, which is a far bigger SEO problem than any plugin setting.

Where 7.1.4 sits in the release calendar

WordPress 7.2 is in beta, and the 7.2 Beta 2 announcement gives 8 December 2026 as the target release date. Running the current branch, with auto-updates working, is the simplest way to stay covered. If you have not started testing 7.2, the staging test plan for 7.2 is a good place to begin.

One more security notice landed in the same fortnight, and it is not a WordPress update at all: on 21 October, WordPress.org warned site owners about a critical PHP security release. WordPress 7.1.4 does not fix that, because the problem is in PHP on the server. The next post covers how to check your PHP version and what to ask your host.