If your website runs on WordPress, there is one thing worth doing today: check which version you are on. On 28 October 2026 the WordPress project released version 7.1.4, a security release, and its announcement says it is recommended that you update your sites immediately.

This article explains what changed in plain language, how serious it really is, and a short checklist you can follow even if you are not technical. I will stick to what the official sources say and mark where something is unknown.

What WordPress 7.1.4 is

WordPress 7.1.4 is a security release published on 28 October 2026. The announcement lists 13 security items. The official version page counts 22 vulnerabilities, because several related issues are grouped together, so you may see either number quoted.

It follows WordPress 7.1.3, which was released on 6 October 2026 with seven security fixes. Two security releases within a month is a good reason to keep automatic updates switched on.

The most serious fix: the update process itself

The headline item is a weakness in the WordPress upgrade process. The announcement describes it as one that can lead to remote code execution during the upgrade window. In simple terms, an attacker could, under the right conditions, make the server run their code while WordPress is in the middle of updating itself. The official documentation describes it as a race condition during core updates.

Security company Patchstack published a technical explanation. Its main points:

  • WordPress unpacks update files into a folder called wp-content/upgrade/. For updates uploaded by an administrator, the folder name was predictable.
  • When cleanup removed a protective index.php file, a copy of WordPress could briefly be browsable, including its installer.
  • The fix adds a random 16-character suffix to the folder name, keeps the protective file in place, and stops the site configuration file from being copied.
  • Patchstack says this is not practical to exploit in most cases, because an attacker needs to hit a window that lasts only seconds.
  • It also says a PHP-level firewall cannot block this one, so updating is the real fix. As an extra step, it suggests blocking web access to the wp-content/upgrade/ folder.

As of 29 October 2026, Patchstack reports no exploitation in the wild for this release. That could change, which is why updating promptly still matters. It is also worth noting that headlines calling this an unauthenticated remote code execution flaw go further than the official wording. The accurate picture is "serious, hard to exploit, and fixed".

The other fixes

The rest of the release is mostly a long list of smaller issues:

  • Several stored cross-site scripting (XSS) problems, in areas such as the Interactivity API, the Customizer, the Categories block, playlist and image blocks and the comments pagination blocks. According to the official documentation, most of these require a user account at Contributor level or higher, and one needs Author level.
  • A stored denial-of-service issue in the Interactivity API.
  • Unpublished Customizer changesets that could be seen by visitors.
  • Post notes that could be read by users who are not allowed to edit the post.
  • An update to the root certificates bundled with WordPress, following an eMudhra certificate revocation. eMudhra revoked eight intermediate certificates after weak keys were found, and Mozilla and Google blocked them on 17 October. eMudhra says most were never used in production and it found no evidence of misuse. For a normal website owner this simply means WordPress now trusts a cleaner list.

The practical reading is that these XSS items matter most to sites with many logged-in users, such as membership sites, stores and sites with several authors. A brochure site with one administrator is less exposed, but it still needs the update, because of the upgrade-process fix.

Older WordPress versions

WordPress says the fixes were backported to every branch that is eligible for security fixes, going back as far as 4.7. The official page lists patched versions for each branch, for example 7.0.8, 6.9.11 and 6.8.12. Backports were still rolling out when the announcement was published, so an older site may not show the update at the same moment.

There is a catch. Only the latest version of WordPress is actively supported, and versions 4.6 and earlier get no fix at all. Staying on an old branch with back-ported patches is a stopgap, not a plan.

What to do: a checklist for non-technical owners

  1. Check your version. Log in to the dashboard and open Dashboard, then Updates. Your version is shown there and at the bottom of the admin screen. The target is 7.1.4, or the latest patch for your branch.
  2. Back up first. Take a full backup of the files and the database, or confirm that your host has a recent one. A backup you have never restored is only a hope, so ask whether it has been tested.
  3. Update from the dashboard. Click Update Now, or download WordPress only from WordPress.org. Do not use links in emails or from unknown websites.
  4. If a host manages your site, ask them in writing. Some hosts apply the update for you and some do not. For example, Pantheon's release note marks action as required, even though it deployed platform-wide mitigations. Do not assume, and confirm the version number afterwards.
  5. Check your plugins and theme too. A WordPress update does not update them. Look for pending updates and remove any plugin you no longer use.
  6. Review your user list. Delete accounts you do not recognise and anyone who no longer needs access, especially Contributor, Author and Editor roles.
  7. Turn on automatic updates for core security releases if your host allows it, and check again a day later that your site really moved to the new version.
  8. Ask your developer about the upgrade folder. Patchstack suggests blocking web access to wp-content/upgrade/ and confirming that the folder has no listable contents.

After updating, open your homepage, a contact form and, if you sell online, test a checkout. Updates rarely break a site, but a two-minute check is cheaper than finding out from a customer.

Why this keeps happening

WordPress runs a very large share of the web, so it receives a lot of attention from researchers and from attackers. That is a strength, because problems are found and fixed in the open. The risk comes from the time between a fix being published and a site actually applying it. Patching routinely, not in a panic, is the cheapest security measure a small business has.

Where I can help

If you are not sure which version you are on, who updates it, or whether your backups work, I can look at it with you. The free Digital Business Audit reviews your current website setup and points out risks like this in plain language. If an ageing WordPress site is the real problem, my website work starts with what your business needs, and every project includes 12-Month Post-Launch Support so that updates and maintenance have an owner after launch.

Sources