WordPress 7.1.3 Security Release:Check Your Site Updated

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 "should" is not the same as "did", and a quick check takes about two minutes.

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 fix is quick, and the risk comes from skipping it.

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 guide is only about getting core onto 7.1.3 and proving it.

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."
• About 5 minutes to check, plus 10 to 15 minutes if you need to update.

Risk level: checking your version is zero risk. Updating core from 7.1.2 to 7.1.3 is low risk, but low is not none, so back up 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.

If your site is current, WordPress tells you that you have the latest version. If 7.1.3 is waiting, you will see an update notice with an Update Now button instead.

Heads up: this screen shows what WordPress last heard from WordPress.org. If the check is old, it may not know about 7.1.3 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.

Look for the Version field. You want it to read 7.1.3.

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 a single line with the number, for example 7.1.3.

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 invented scenario, but it is very common.

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 7.1.3, something stopped the background update. Here are the usual causes and how to spot 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 update to 7.1.3 safely

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.

The official guide says you should not need to do anything else, and once it finishes you are up to date.

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 this only if the dashboard and WP-CLI both fail. The official download for this release is at https://wordpress.org/wordpress-7.1.3.zip.

The official manual steps, in short:

1. Download the 7.1.3 zip and unpack it on your computer.
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, overwriting existing files.
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.

Heads up: never delete your existing wp-content folder. That is where your themes, plugins and uploads live. The official guide also reassures you that your wp-config.php will be safe.

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 planning a move to 7.1.3 is the better path.

How to check it worked

Do these checks right after the update. Each one should take a few seconds.

1. Go to Tools > Site Health > Info > WordPress and confirm Version reads 7.1.3.
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 is 7.1.3.
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 every core file on your server with the official fingerprints from WordPress.org. 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: enter the credentials for that FTP account to finish the update. For a lasting fix, ask your host to correct the file ownership so the web server can update WordPress on its own. Otherwise, future background updates will keep failing in the same quiet way.

The Updates screen does not show 7.1.3

Symptom: your version is 7.1.2 or older, 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, though with a small security release this is rare.

Fix: turn on the debug log the safe way (not on screen for visitors) and read the first real error. Our guide on how to use the WordPress debug log safely after an update shows how. If the site is down and you need it back now, restore the backup you took in Step 1, then investigate on a copy.

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:

Hi, WordPress 7.1.3 was released on 6 October 2026 with 7 security fixes, and WordPress recommends updating immediately. Could you please confirm our site is on 7.1.3 (Tools > Site Health > Info > WordPress > Version, or "wp core version")? If it is not, please take a database and files backup, update core, and run "wp core verify-checksums" afterwards. Also, please check whether wp-config.php has AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE set to block updates, and let me know why if it does. Thanks!

The takeaway: do not assume the auto-update ran; checking your version takes two minutes and turns "probably updated" into "definitely updated".