WordPress 7.1.4 Security Update: What to Do Now

If you run a WordPress site, the WordPress 7.1.4 security update is the one to install today. It came out on 28 October 2026, and the project's advice is short: update immediately. This post explains what is in it, what the sources do not say, and how to update without breaking your site.

What WordPress 7.1.4 is

WordPress 7.1.4 is a security release. The release post says: "On October 28, 2026, WordPress 7.1.4 was released to the public." It also says "it is recommended that you update your sites immediately."

The HelpHub page for 7.1.4 gives a wider count. It says versions are "affected by all 22 vulnerabilities". The release post itself lists 13 summary items. So 22 is HelpHub's figure, and the two pages group things differently. Treat the number as "a lot of fixes", not as a precise score.

This follows 7.1.3 on 6 October and a Critical PHP Security Release on 21 October, according to the WordPress security category. Three security-related releases in a month is a good reason to look at how your site gets updates.

What the release fixes

Here is the list in plain terms, based on both WordPress pages.

The upgrade process itself. The release post describes a weakness that "can lead to remote code execution during the upgrade window". It credits the reporter, Umut Bayram. HelpHub calls it a race condition during core updates. Neither page explains how it works, and we will not guess. What matters is that the fix is in the update path, so you want to be on 7.1.4 or a patched branch.

Stored cross-site scripting (XSS). This is the largest group. Stored XSS means someone saves script content that later runs in another person's browser. The fixes touch:

• block markup and block delimiters
• privacy data erasure requests
• the Interactivity API (several)
• Customizer selective refresh
• the Categories block
• the Playlist and Image blocks
• the Comments Pagination blocks
• usernames, and hardening of the multisite Network Users screens

The two pages word the username item differently, so we describe it loosely here. Check both pages for the exact text.

A stored denial of service. HelpHub mentions "stored cross-site scripting (XSS) and denial of service issues in Interactivity API bindings".

Information disclosure. Unpublished Customizer changes could be shown to unauthenticated visitors, per HelpHub.

A permissions issue. HelpHub says custom roles that moderate comments could "read, edit and delete notes on posts they can't edit".

Root certificates. The release bundles updated root certificates "due to the eMudhra revocation". WordPress gives no more detail than that.

How worried should you be?

Be prompt, not frightened. Here is what the sources do and do not say.

• Neither the release post nor HelpHub lists CVE IDs. We checked the release post for any wording about active exploitation and found none.
• Most of the XSS items need someone with a login, such as a Contributor or an Editor, to plant the content. They are not all remote attacks from a stranger. The upgrade-window issue is the exception that WordPress describes as remote code execution, so do not lump everything together.
• "No exploitation reported" is not the same as "no exploitation". Details often become public after a fix ships, and attackers read patch notes too.

Our opinion, not official guidance: if your site has many authors, a public comment form, a custom login flow, or custom roles, you have more ways for a logged-in user to reach these code paths. Give those sites priority.

The eMudhra certificate part

The certificate line in the release notes links to a wider story. Cloudflare says it learned on 19 October 2026 that private keys for eight eMudhra intermediate certificates were compromised. In its post on the incident, Cloudflare says its review "has not identified active exploitation of this issue on Cloudflare services." That statement covers Cloudflare's own services only.

Cloudflare also warns against fixing certificate errors by disabling verification. It tells customers to update clients, cloudflared and container images, and to review their mTLS trust stores. As of 29 October 2026, Cloudflare describes its remediation as ongoing, so check that post for updates.

For a WordPress site owner, the practical point is simple. Updating core brings the new root certificate bundle. If your site makes outgoing HTTPS requests, for example to payment, shipping or API services, never "solve" a certificate error by turning off verification. Update instead.

Update steps for the WordPress 7.1.4 security update

1. Check your version. In the dashboard, open Dashboard > Updates. If you already see 7.1.4, you are done.
2. Back up. Take a database and files backup, and confirm you can restore it.
3. Use staging if you have it. Apply the update there first. Check logins, contact forms, search, checkout and any custom blocks.
4. Update. WordPress says you can update automatically from the Dashboard > Updates menu, or download the release from wordpress.org. Sites with automatic background updates get it automatically: "the update process will begin automatically."
5. Test the live site. Log in as an editor, load your key pages, send a test form.
6. Review accounts. Remove users you no longer need, and check which roles can publish or moderate. Our opinion: fewer powerful accounts means less to worry about the next time a stored XSS fix lands.

If your host or a plugin pins your WordPress version, check that setting too. A pinned version is a common reason a site misses a security release.

If you are on an older branch

WordPress says "only the most recent version of WordPress is actively supported." It also backports fixes to older branches as a courtesy, going back to 4.7. Branch releases named on HelpHub include 7.0.8, 6.9.11, 6.8.12 and 4.7.39. WordPress 4.6 and earlier "no longer receive security updates."

Be careful with the status of those backports. The release post says they "are in progress and will ship as they become ready", while HelpHub lists them as already released. As of 29 October 2026 the pages disagree, so check HelpHub for your branch before you assume you are covered. If you are on an old branch, the better plan is to move to the current version.

The fixes are also in WordPress 7.2 Beta 3. The final 7.2 release is "currently planned for December 8th", but that date can move.

What to do next

• Update to 7.1.4 today, or confirm that your site has done so already.
• Take a backup first and test the important pages after.
• If you are on an older branch, check HelpHub for your branch release, and plan a move to the current version.
• Re-read the release post in a few days, because more detail may be published later.

If you would rather hand this over, talk to Paraline Tech about WordPress maintenance and update testing.