WordPress 7.1.3 Security Release: Check and Update Beyond It

Update checked 4 November 2026: This article explains the historical WordPress 7.1.3 release of 6 October. It is no longer the current update target. WordPress 7.1.4 was released on 28 October and is the latest stable release in the official archive at this review. Use our 7.1.4 update guide for that release, and recheck the archive before acting. WordPress 7.2 beta releases are for testing, not the production update target in this guide.

WordPress 7.1.3 came out on 6 October 2026 with seven security fixes and four bug fixes. The WordPress team says to update right away. Sites that support automatic background updates should receive it on their own, but the existence of an automatic-update feature does not confirm that a particular site completed the update.

An auto-update can be switched off by one line in wp-config.php that someone added years ago, and the dashboard will not shout about it. Your site can sit on 7.1.2 for weeks while you assume it is safe.

By the end of this guide you will be able to confirm your exact WordPress version in three different ways, find out why an auto-update did not run, update safely if you are behind, and prove the update worked.

What a WordPress security release actually is

A security release is a small update (the last number in the version goes up, so 7.1.2 becomes 7.1.3) that closes holes attackers could use. The release post describes 7.1.3 as a security and maintenance release with 7 security fixes and 4 bug fixes.

Think of it like a recall notice for your car. The car still drives fine, and nothing looks wrong, but the maker found a faulty part. The repair still needs a backup, compatibility checks and verification.

WordPress calls these "minor" releases. By default, WordPress installs minor updates on its own in the background. The official handbook says that "by default, automatic updates of WordPress are enabled on most sites." The word "most" matters, and we will come back to it.

Quick tip: if you just did the 7.1.2 update a few weeks ago, you do not need to repeat that whole routine. The plugin, theme and PHP checks are covered in our WordPress 7.1.2 security update checklist. This page preserves the 7.1.3 release context; its operational checks now point readers to the current stable release rather than stopping at 7.1.3.

The seven fixes in plain words

At the time of writing (13 October 2026), the official release post lists these security fixes in 7.1.3:

• A stored XSS problem on the Comments admin page, triggered through pending comments. XSS (cross-site scripting) means an attacker sneaks script code into a page that someone else then opens.
• A denial-of-service issue in the WP_Http::make_absolute_url() method. Denial of service means a request that can tie up or crash the site.
• A second-order SQL injection in the WXR export. WXR is the export file WordPress creates when you move content to another site. Second-order means the harmful data is stored first and only does damage later.
• A weakness that let users with the Author role make posts sticky (pinned to the top of the blog page), something that role was not meant to do.
• Unauthenticated disclosure of comments on private and unpublished posts. In plain words, people who were not logged in could read comments they should never see.
• XSS in Imgur embeds.
• Forgeable parameters in the {status}_{type} hook that could cause action name collisions. A hook is a point where plugins plug in their own code.

The post also mentions four bug fixes but does not describe them; it links to a list on WordPress Trac (the WordPress bug tracker). The release post does not publish CVE numbers, so do not trust any article that lists them without a source.

Several of these fixes involve comments. If your site accepts comments, especially from people who are not logged in, you are exactly the kind of site these fixes protect.

Before you start

You do not need much, but get these ready first:

• An administrator login for the WordPress dashboard.
• Optional: SSH access to your hosting account and WP-CLI (the WordPress command-line tool), if you prefer the terminal.
• Optional: FTP or your host's file manager, in case an update gets stuck.
• A fresh backup of both the database and the files. The official backup guide says you need both "to be able to fully restore a typical WordPress site."
• A maintenance window appropriate for the site, backup, compatibility checks and recovery. Examples below are documentation-based and were not executed against a reader’s website.

Checking the version does not itself install an update. Commands that load WordPress can execute site or local WP-CLI configuration code, so use trusted inspection for a suspected compromise. Updates change files and can require database changes; back up and prepare recovery first.

If you do not have a backup routine yet, our guide on how to back up a website in cPanel, keep an offsite copy and test the restore walks through it step by step.

How to see which version your site is running

You only need one of these methods. Use two if you want to be sure.

Step 1: Check the Updates screen

Log in to your dashboard and go to Dashboard > Updates.

The Updates screen reports the latest version known to its update check. Compare it with the current official stable release; an old cached result is not sufficient confirmation.

Heads up: this screen shows what WordPress last heard from WordPress.org. If the check is old, it may not know about the latest release yet. The WP-CLI method below can force a fresh check.

Step 2: Confirm in Site Health

Go to Tools > Site Health, then open the Info tab and expand the WordPress section.

As checked on 4 November 2026, the latest stable release is 7.1.4. Compare the Version field with the official release archive when you act. Seeing 7.1.3 confirms that historical version, not current patch status.

While you are in Site Health, look at the Status tab too. It groups items into critical issues, recommended improvements and passed tests, and it flags things like "You have plugins waiting to be updated" and an outdated PHP version. It can also warn about problems that stop updates working, such as WordPress.org being unreachable. Note that its documented auto-update warning example is about plugins and themes, so do not rely on it alone to tell you whether core auto-updates are blocked in wp-config.php.

Step 3: Check from the command line with WP-CLI

If you have SSH access, move into the folder where WordPress is installed (the one with wp-config.php in it). The command below prints just the version number:

wp core version

You should see the installed version on one line. For example, 7.1.3 means that older version is installed; it is not the expected current target at this review.

For more detail, this command also shows the database revision and the language package:

wp core version --extra

To ask WordPress.org right now whether a newer version exists, this command skips the cached result and does a fresh check:

wp core check-update --force-check

If an update is available, you get a small table with the version, the update type and the download link. If you are already up to date, WP-CLI prints a success message instead.

Made-up example: the site that "always auto-updates"

This is an illustrative scenario, not a reported customer incident.

Amina runs a small bakery site. Her developer built it in 2023 and added a line to wp-config.php to stop automatic updates during a big redesign. The redesign finished, the developer moved on, and the line stayed.

Every few months Amina logs in, sees nothing alarming, and logs out. Her site is still on 7.1.1. It missed 7.1.2 and now 7.1.3, and her comment form is open to the public.

Nothing looked broken. That is the whole problem, and it is why the next section exists.

Why your auto-update might not have run

If your version is older than the current stable release, do not assume the background updater is working. It may be disabled intentionally, host-managed or blocked by an error. Here are common causes and how to check each one.

A setting in the config file turned updates off

WordPress reads a few settings, called constants, from wp-config.php. Two of them can block core updates.

The official handbook shows that this line disables all automatic updates:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

And this line disables all core updates:

define( 'WP_AUTO_UPDATE_CORE', false );

The default setting, which allows minor (maintenance and security) updates, looks like this:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

To find either constant quickly over SSH, run this search from the WordPress folder. It prints any matching lines with their line numbers:

grep -n "AUTOMATIC_UPDATER_DISABLED\|WP_AUTO_UPDATE_CORE" wp-config.php

No matches only means this search found neither constant; filters, plugins or host controls may still change update behavior. A true disabled-updater constant or false core-update constant blocks the relevant automatic updates.

Heads up: do not delete these lines blindly. Someone may have added them on purpose, for example because the host manages updates for you, or because the site needs testing first. Ask before you change them. Our guide to WordPress auto-updates with a safe backup plan helps you decide which setting fits your site.

File permissions stopped the update

The official update guide says that when one-click updates have problems, "it is probably related to permissions issues on the filesystem." If WordPress cannot write its own files, the background update cannot finish either.

A sign of this is a box asking for FTP connection details when you click Update Now. More on that in Troubleshooting below.

Your site cannot reach WordPress.org

Updates are downloaded from WordPress.org. Site Health's Status tab flags it when WordPress.org cannot be reached, and when HTTP requests are blocked. A firewall rule or a broken outgoing connection on the server can quietly stop updates.

Your host handles updates

The handbook mentions "host supplied updates" as one reason a site might not auto-update. Some hosts turn off the WordPress updater and roll out updates on their own schedule. If that is your setup, the fix is a message to your host, not a change in wp-config.php.

How to move from 7.1.3 to the current stable release

If you are behind, here is how to catch up. Pick one method: the dashboard, WP-CLI, or a manual upload.

Step 1: Take a backup first

The official update guide puts it simply: "Before you get started, it's a good idea to back up your website."

Back up both parts:

• The database (posts, pages, comments, settings, users).
• The files (themes, plugins, uploads and wp-config.php).

The backup handbook also recommends keeping several recent backups in different places, such as your server, cloud storage and your own computer. A backup that only lives on the same server as the site does not help much if that server has a bad day.

Quick tip: write down the version you are on before you update, for example "7.1.1". If you ever need to roll back, you will know exactly what to restore.

Step 2: Update from the dashboard

Go to Dashboard > Updates and click Update Now.

After the updater completes, confirm the installed version and test the site; an updater success message alone does not verify forms, checkout or plugin compatibility.

Quick tip: leave the tab open and wait for the process to finish before you click anywhere else.

Step 3: Or update with WP-CLI

If you prefer the terminal, this command updates WordPress core to the latest version:

wp core update

If you only want minor releases (so 7.1.x moves to the newest 7.1.x, and a future major version is not pulled in), add the --minor flag:

wp core update --minor

A successful run ends with this line:

Success: WordPress updated successfully.

After a core update, this command runs the WordPress database update routine, in case the new version needs one:

wp core update-db

Step 4: Or update manually with the zip file

Use a manual upload only if the dashboard and WP-CLI paths fail and you can follow the full official instructions. The official download for this historical 7.1.3 release is at https://wordpress.org/wordpress-7.1.3.zip. Before acting, use the current stable package from WordPress.org if a later release has superseded it.

The official manual steps, in short:

1. Download the current stable package from WordPress.org and unpack it on your computer. Do not use the historical 7.1.3 package as a new update target.
2. Deactivate your plugins.
3. Delete the old wp-includes and wp-admin folders on your server, using FTP or SSH.
4. Upload the new wp-includes and wp-admin folders in their place.
5. Upload the individual files from the new wp-content folder into your existing wp-content folder; never replace the whole directory. Before overwriting a default or classic theme, check whether someone edited its files directly—those customizations can be lost. Follow the official manual-upgrade guide for exceptions.
6. Upload all the new loose files from the root of the package to your WordPress root folder.
7. Visit /wp-admin, follow the database update link if WordPress shows one, then reactivate your plugins.

Never delete the existing wp-content folder or wp-config.php. Back up .htaccess and all files privately first; a full WordPress update can overwrite edited core or bundled theme files, so review local modifications before replacing them.

Full instructions are on the official Updating WordPress page.

What if I am on an older branch, not 7.1?

At the 6 October 2026 announcement, the WordPress team said security backports to eligible older branches, through 4.7, were in progress and would ship when ready. That announcement does not establish the completion status of every branch today. Check the exact patched point release for your branch rather than assuming that an older major version is protected.

The same post notes that only the most recent version is actively supported. If you are stuck on an older branch, a security backport keeps you safer for now, but plan and test a move to the current actively supported stable release.

How to check it worked

Do these checks after the update and allow enough time to exercise the site’s important functions.

1. Go to Tools > Site Health > Info > WordPress and compare Version with the current stable target you selected (7.1.4 at this review).
2. Go to Dashboard > Updates and confirm WordPress says you have the latest version.
3. Run the version check over SSH and confirm the output matches that same current stable target.
4. Verify the core files against the official checksums (see below).
5. Open the home page, one post with comments, and the Comments screen in the dashboard, and make sure they all load normally.

The checksum command compares covered core files with the official fingerprints for the installed version and locale. It does not audit the whole website. Checksums are like a seal on a medicine bottle: if a file was changed, the seal does not match. Run it from the WordPress folder:

wp core verify-checksums

A clean install prints this:

Success: WordPress installation verifies against checksums.

If a file does not match, you will see a warning naming the file, such as Warning: File doesn't verify against checksum: wp-includes/version.php, followed by an error that the installation does not verify. That can mean a half-finished update or a modified file, so treat it seriously.

A version number only tells you what WordPress thinks it is. The checksum check compares core files with official checksums for the installed version. It does not audit plugins, uploads or the database, or prove the whole site is malware-free.

Troubleshooting

"Failed update" message that will not go away

Symptom: after an interrupted update, the dashboard keeps showing a failed update notice.

Likely cause: a leftover file called .maintenance in your WordPress folder.

Fix: first confirm no update is still running. For an interrupted update, the official guide says to delete the leftover .maintenance file from your WordPress folder using FTP. Files that start with a dot are hidden by default in many FTP apps and file managers, so turn on "show hidden files" first. Then run the update again.

WordPress asks for FTP connection details

Symptom: you click Update Now and get a form asking for an FTP hostname, username and password.

Likely cause: the official guide explains that WordPress will not write new files if they would not have the correct ownership. The files are often owned by the FTP account that first uploaded them.

Fix: ask your host to check ownership and the supported secure update method. Do not loosen permissions broadly or send credentials over an unencrypted connection. Confirm why access is failing before changing the filesystem or saved credentials.

The Updates screen does not show the current stable release

Symptom: the installed version is older than the official stable release, but Dashboard > Updates shows no update.

Likely cause: the last update check is cached, or the site cannot reach WordPress.org.

Fix: run wp core check-update --force-check to bypass the cache. If that fails too, open Tools > Site Health > Status and look for warnings about WordPress.org being unreachable or HTTP requests being blocked, then send those warnings to your host.

The checksum check fails after the update

Symptom: wp core verify-checksums prints a warning naming one or more core files.

Likely cause: the update did not finish, or a core file was edited (by a person, a plugin, or in a worse case, an attacker).

Fix: re-install the current version from Dashboard > Updates if WordPress offers a re-install button, or run the manual update with the official zip. Then run the checksum command again. If the same file keeps failing, or you see files you do not recognise, ask a developer or your host to investigate.

A database update prompt appears

Symptom: after a manual update, visiting /wp-admin shows a message that a database update is needed.

Likely cause: this is normal. The new files expect a newer database structure.

Fix: click the link WordPress gives you (a URL ending in wp-admin/upgrade.php), or run wp core update-db. Your posts and settings stay where they are.

The site shows errors after updating

Symptom: a white screen, a critical error message, or a broken page after the update.

Likely cause: a plugin or theme clashing with a core change, so investigate the actual error instead of assuming the cause from the release size.

Fix: inspect the error log without showing details to visitors, identify the failing component and test a repair on a copy where practical. Our guide on how to use the WordPress debug log safely after an update shows how. If recovery requires the pre-update backup, preserve orders, registrations and other changes since that backup before restoring a live database. An old vulnerable version should not remain publicly exposed while you plan a secure fix.

When to ask your host or a developer

You can handle most of this yourself. Ask for help when:

• wp-config.php contains a constant that blocks updates and you do not know who added it or why.
• File ownership needs fixing, which usually means server-level access you may not have.
• The checksum check keeps failing on the same file after a clean re-install.
• You run many sites and cannot check each one by hand.

The one message worth forwarding

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

Please confirm our installed WordPress version against the current official stable release. WordPress 7.1.4 superseded 7.1.3 on 28 October 2026; check whether a newer stable release is available when you act. Back up files and the database, plan compatibility and recovery checks, update as appropriate, then verify the version, covered core checksums and important site functions. Please also explain any settings or host controls that intentionally disable automatic updates.

Confirm the installed version, compare it with the current official stable release and test the site after updating. A version or checksum check has a defined scope and does not prove the whole site is secure.