Get the WordPress 7.1.3 and 7.1.4 Fixes and Verify Them With WP-CLI

If your WordPress site is still on 7.1.2 or older, update it now, then prove the update worked with two WP-CLI commands: wp core version and wp core verify-checksums. At the time of writing (31 October 2026), the newest release is WordPress 7.1.4, so updating today gets you the 7.1.3 security fixes and the 7.1.4 ones in one go.

Here is the part that surprised me. WordPress 7.1.3 came out on 6 October 2026 with 7 security fixes, and only three weeks later, on 28 October, WordPress 7.1.4 followed with 13 more listed fixes. If you updated once in early October and then stopped looking, you are already one security release behind.

By the end of this guide you will be able to check your version and PHP, take a backup, update from the Dashboard or with WP-CLI, and confirm with real evidence that your core files match the official release.

What a WordPress security release actually is

A security release is a small update that fixes known weaknesses without adding big new features. WordPress calls 7.1.3 a "maintenance and security release": it contains 7 security fixes and 4 bug fixes. The version number tells you this: the last digit changed (7.1.2 to 7.1.3), which means a minor release on the same branch.

Think of it like a recall notice for your car. The car still drives the same, nothing looks different from the outside, but the garage replaces a part that could fail. You do not notice the fix. You only notice if you skip it.

These are the 7 security issues the official 7.1.3 announcement lists, in its own words where possible:

• A stored XSS on the Comments administration page, exploitable via pending comments.
• A denial of service issue in the WP_Http::make_absolute_url() method.
• A second-order SQL injection in the WordPress WXR export.
• A weakness that let users with the Author role make posts sticky.
• Unauthenticated disclosure of comments on private and unpublished posts.
• An XSS issue in Imgur embeds.
• Forgeable parameters passed to the {status}_{type} hook that can lead to an action name collision.

A few plain definitions. XSS (cross-site scripting) means someone gets their own script to run in another person's browser on your site. SQL injection means someone sneaks database commands into a request. WXR is the "WordPress eXtended RSS" file you get from the export tool. Denial of service means a request that ties up the server so real visitors cannot get through.

The announcement does not give CVE numbers or severity scores, so I will not guess how easy any of these are to abuse. What it does say clearly is this: "it is recommended that you update your sites immediately."

Then came 7.1.4 on 28 October 2026. Its announcement lists 13 items, including "A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window", several stored XSS issues in blocks and the Interactivity API, and an update to the bundled root certificates. Again, no CVE numbers or severities are given. Because 7.1.4 is the next release on the same 7.1 branch, updating to it also brings in everything from 7.1.3.

Why this matters: two of the 7.1.3 fixes touch the exact screens many site owners use every week, the Comments page and the export tool. That is why the checks later in this guide include a quick look at both.

Before you start

Run through this list first. It takes five minutes and saves you from the worst kind of afternoon.

• Access: an Administrator login for the WordPress Dashboard.
• Optional, for the WP-CLI route: SSH access to the server and WP-CLI installed. If you type wp and get "command not found", use the Dashboard route instead.
• Hosting panel login: so you can use the host's backup tool or file manager if something goes wrong.
• PHP version: WordPress 7.0 raised the minimum PHP version from 7.2.24 to 7.4, so your server must run PHP 7.4 or newer.
• Backup: a fresh copy of your database and your wp-content folder, made today. Step 2 covers this.
• Time: about 15 minutes for one site, including checks.
• Risk level: low. Minor releases on the same branch are small, and the backup covers you if a plugin misbehaves.

Quick tip: if you manage several sites, do the smallest, least important one first. You learn what your hosting setup does during an update with nothing important on the line.

Made-up example: Priya runs a small bakery site. She clicked Update Now for 7.1.3 in early October and felt done. On 31 October she logs in for an unrelated reason, sees an update banner for 7.1.4, and realises her site does not auto-update core. This guide is the 15 minutes she spends fixing that properly.

Update WordPress step by step

Step 1: Check your current version and PHP

First, find out where you are. In the Dashboard, go to Tools > Site Health > Info. Open the WordPress section and look at Version. Then open the Server section, which lists your server and PHP details.

If you have SSH and WP-CLI, this command prints the installed WordPress version.

wp core version

You should see a single version number, for example 7.1.2. Anything lower than 7.1.4 needs this update.

This command shows details about the WP-CLI environment, including the PHP binary and PHP version WP-CLI is using.

wp cli info

Look for the PHP version: line in the output. Heads up: on some servers the PHP used on the command line is a different build from the one serving your website, so trust the Site Health screen for the website's PHP version.

This command asks the WordPress Version Check API whether an update is available.

wp core check-update

What you should see: a small table with the columns version, update_type and package_url. If it lists 7.1.4 or something newer, you have an update waiting.

About PHP: the WordPress hosting handbook for 7.0 recommends PHP 8.4 or 8.5 for new installations and notes that "PHP 8.1 reached end of life on 31 December 2025." The WordPress.org download page says "Recommend PHP 8.3 or greater." If you are on 8.1 or older, the core update will still work as long as you are on 7.4 or newer, but plan a PHP upgrade with your host soon after.

Step 2: Back up your database and files

The official update guide says it is a good idea to back up your website before you start, so you can restore if anything goes wrong. A backup has two parts: the database (posts, pages, settings, users) and the files (mainly wp-content, where your themes, plugins and uploads live).

The easiest route is your hosting control panel's backup tool. Make a new backup now and confirm it shows today's date. Do not rely on a backup from last week.

If you have WP-CLI, this command exports the whole database to a SQL file in the current folder, using the file name you give it.

wp db export before-update.sql

You should see a line like Success: Exported to 'before-update.sql'. If you leave the file name out, WP-CLI picks one for you using the pattern {dbname}-{Y-m-d}-{random-hash}.sql.

Heads up: that SQL file contains your user table and settings. Move it out of the public web folder or download it to your computer, then delete it from the server once the update is done and checked.

For the files, download your wp-content folder with your host's file manager or an FTP client, or rely on the host's full backup if it includes files. The update only replaces WordPress core files, but plugins and themes are what you would hate to lose, so they belong in the backup.

Step 3: Update from the Dashboard

This is the route most people should use. Go to Dashboard > Updates. On the "Update WordPress" screen, click Update Now. You can also click the link in the new version banner at the top of the admin area if you see one.

What you should see: a progress screen, then the WordPress welcome or "About" screen for the new version. The official guide says you should not need to do anything else.

Heads up: if a box appears asking for FTP or connection details, stop and jump to the Troubleshooting section. That box is about file ownership, not about the update itself.

Step 3 (WP-CLI alternative): Update from the command line

If you prefer SSH, this command updates WordPress core to the latest available version.

wp core update

What you should see, roughly: Updating to version 7.1.4 (en_US)..., then lines about downloading and unpacking, then Success: WordPress updated successfully.

If you want to stay on the 7.1 branch no matter what else is released, this command only performs updates for minor releases (for example 4.3 to 4.3.3, in the docs' own example).

wp core update --minor

Quick tip: you will see an --insecure flag in the WP-CLI docs. It retries the download without certificate validation, and the docs warn that "This makes the request vulnerable to a MITM attack." Leave it alone on a security update.

Step 4: Run the database update if WordPress asks

Most minor releases do not need a database change, but some do. In the Dashboard, WordPress tells you if one is needed and gives you a link to wp-admin/upgrade.php. Click it and follow the prompt.

With WP-CLI, this command compares database versions without changing anything, so you can see if an update is needed.

wp core update-db --dry-run

If it reports that an update is needed, this command runs the database update procedure for real.

wp core update-db

On a multisite network, this command updates the database for every site on the network.

wp core update-db --network

What you should see: a Success: line. On a network you get a count such as how many sites were upgraded out of the total.

How to check it worked

An update screen that says "success" is a good sign. Proof is better. Here are four checks, from quickest to most thorough.

Check 1: The version number

This command prints the installed version again.

wp core version

Expected result: 7.1.4 (or a newer release, if one has come out since 31 October 2026). Without WP-CLI, check Tools > Site Health > Info and open the WordPress section.

This command shows extended version information, including the database revision and the package language.

wp core version --extra

The Package language: line matters for the next check. If it says something other than en_US, you will pass that locale to the checksum command.

Check 2: Verify core files against official checksums

This is the most useful check in the whole guide. A checksum is a fingerprint of a file. WP-CLI downloads the official fingerprints from WordPress.org and compares each core file on your server with them.

This command verifies your WordPress core files against the official checksums.

wp core verify-checksums

Expected result: Success: WordPress installation verifies against checksums.

If your site uses a language pack, this command checks against the checksums for that locale (replace ja with your own locale).

wp core verify-checksums --locale=ja

This command also checks the root directory and warns about any non-WordPress items found there.

wp core verify-checksums --include-root

Why this matters: a successful update replaces core files, but it cannot tell you whether someone added an extra file earlier. The --include-root run lists extra items in the WordPress root folder. Some will be yours (a .htaccess file, a verification file from a search tool). Anything you do not recognise is worth asking your host about.

Check 3: Look at the Comments screen

The first 7.1.3 fix was a stored XSS on the Comments administration page via pending comments. Go to Comments in the left menu and click the Pending filter at the top. The list should load normally, and you should be able to approve, mark as spam or trash a comment as usual.

If you have a pile of pending comments from addresses you do not know, this is a good moment to clear them. Use the Spam action rather than approving anything you are unsure about.

Check 4: Run a test export

Another 7.1.3 fix was in the WXR export. Go to Tools > Export, choose Posts, narrow it with a date range of one month to keep the file small, and click Download Export File.

What you should see: your browser downloads an XML file. Open it in a text editor and check it contains the posts you expected. Then delete the file from your computer if you do not need it, because exports can contain author names and email addresses.

Troubleshooting

The site shows a maintenance message or a "failed update" nag

Symptom: after a timeout or a closed browser tab during the update, the admin area shows a "failed update" message, or visitors see a maintenance notice instead of your site. Cause: an interrupted update can leave a file called .maintenance in your WordPress directory. Fix: the official guide says to delete .maintenance from your WordPress directory, then run the update again.

With WP-CLI, this command displays whether maintenance mode is currently active.

wp maintenance-mode status

If it says Maintenance mode is active., this command turns it off.

wp maintenance-mode deactivate

You should see Success: Deactivated Maintenance mode. Then run wp core update again and do the checks above.

WordPress asks for FTP or connection credentials

Symptom: when you click Update Now, a box asks for a hostname, FTP username and password. Cause: according to the official update guide, WordPress picks how to write files based on who owns them. If the files are not owned by the user the web server runs as, WordPress will not write them directly and asks for credentials instead. Fix: either enter the FTP account details that originally uploaded the files, or ask your host to fix file ownership so updates work without the prompt.

verify-checksums prints warnings

Symptom: lines like Warning: File doesn't verify against checksum: wp-includes/version.php followed by Error: WordPress installation doesn't verify against checksums. Cause: either you checked against the wrong locale, or a core file was changed after it was installed. Fix: run wp core version --extra, note the package language, and rerun with --locale= set to it. If warnings remain, a core file really differs from the official one. Replace the core files by following the official manual update steps (new wp-admin and wp-includes folders, plus the loose root files) and then ask your host to check the site for unwanted changes.

The version still shows the old number

Symptom: the update said success, but the site or the Updates screen still shows the older version. Cause: often a page cache or a server cache serving old pages. Fix: the official guide says to clear the cache after updating so changes go live. Clear your caching plugin and any host cache, then run wp core version again, which reads the files directly.

WordPress sends you to upgrade.php

Symptom: after updating, the admin area shows a screen asking you to update the database. Cause: the new release needs a database change. Fix: click the button, or run wp core update-db from Step 4. Do this straight away, because the official guide says to do it as soon as possible after the files are replaced.

Your PHP version is too old

Symptom: the Status tab in Tools > Site Health flags "Your site is running an outdated version of PHP, which requires an update". Cause: WordPress 7.x needs PHP 7.4 or newer. Fix: in your hosting panel, switch the site to a newer PHP version (the download page recommends 8.3 or greater), test the site, then update WordPress.

wp: command not found

Symptom: your shell says wp: command not found. Cause: WP-CLI is not installed or not on your path for that account. Fix: use the Dashboard route for now, and ask your host whether WP-CLI is available on your plan.

Keep it updated after today

Getting to 7.1.4 today is the main job. Staying current is the follow-up, and three things help.

First, check whether background updates actually run on your site. The 7.1.3 and 7.1.4 announcements both say sites that support automatic background updates start the update by themselves. It is worth checking rather than assuming, and there is a separate guide on how to check whether WordPress auto-updates really run.

Second, keep the attack surface small. If you do not use the XML-RPC interface, the guide on how to disable WordPress XML-RPC safely shows how to turn it off without breaking apps that still need it.

Third, about older branches. The 7.1.3 announcement says security fixes are being backported to branches eligible for security fixes, currently through 4.7, but that only the most recent version is actively supported. Backports ship as they become ready, so check wordpress.org/news for the current status before assuming an old branch is patched. The honest advice is to get onto 7.1.x.

Quick tip: WordPress 7.2 is scheduled for 8 December 2026. That is a major release, so treat it as a separate, planned update with its own backup and testing, not something to rush on a Friday.

The one message worth forwarding

If someone else looks after your site, copy and send this:

"Hi, WordPress 7.1.3 (6 Oct) and 7.1.4 (28 Oct) are both security releases, and WordPress recommends updating immediately. Could you please back up the database and wp-content, update core to 7.1.4 or newer, then run wp core version and wp core verify-checksums and send me the output? Please also confirm the site's PHP version is 7.4 or newer, and ideally 8.3 or newer. Thanks."

Update today, then trust the checksum result rather than the progress bar.