WordPress 7.1.3 came out on October 6, 2026. It is a maintenance and security release with seven security fixes and four bug fixes. The WordPress team asks all site owners to update right away. Fixes have also been backported to every older branch that still gets security support, which currently goes back to 4.7. If you run one WordPress site, this takes a few minutes. If you run dozens on a cPanel or VPS server, you need to confirm that each site actually updated rather than assuming automatic updates handled it. This post covers what the release fixes, who should care most, and how to roll it out and check the result.
What WordPress 7.1.3 fixes
The seven security issues cover several parts of core. None of them is a headline remote takeover. Several, though, can be chained with weak user accounts or untrusted content, and that is exactly how WordPress sites usually get compromised.
| Issue | Area | Who should care most |
|---|---|---|
| Stored cross-site scripting through pending comments | Comments admin screen | Sites with open comments |
Denial of service in WP_Http::make_absolute_url() |
HTTP API | All sites |
| Second-order SQL injection | WXR export | Sites with several editors or authors |
| Authors able to make posts sticky | Permissions | Multi-author blogs and newsrooms |
| Unauthenticated disclosure of comments on private and unpublished posts | Comments | Sites that keep drafts or private posts |
| Cross-site scripting in Imgur embeds | Embeds | Sites that allow embeds in content |
Action name collisions from forgeable parameters in the {status}_{type} hook |
Hooks API | Sites running plugins that rely on these hooks |
The reporters included Trail of Bits working with OpenAI, Anthropic, Patchstack, independent researchers and the WordPress security team. AI-assisted auditing now finds bugs in widely used projects faster than before, so expect point releases like this one to come more often. Your update process should be able to keep up.
The release notes list four bug fixes but do not describe them. The details are in the 7.1.3 milestone on WordPress Trac.
Will your sites update on their own?
By default, WordPress installs minor and security releases automatically, so many sites will already be on 7.1.3. Automatic updates can still fail without anyone noticing. Common reasons:
WP_AUTO_UPDATE_COREis set tofalse, orAUTOMATIC_UPDATER_DISABLEDis set, inwp-config.php.- Files are owned by a different user than the one PHP runs as, so WordPress cannot write to them.
- WP-Cron does not run because the site gets little traffic or
DISABLE_WP_CRONis set without a real system cron job to replace it. - The site is under version control or deployed from a build pipeline, so core files are read-only on the server by design.
- A security or management plugin is blocking core updates.
On a site you manage by hand, open Dashboard > Updates. The page should report version 7.1.3 or the latest backport release for your branch.
Updating and verifying with WP-CLI
If you have shell access, WP-CLI is the fastest way to update and check a site. Run it as the account that owns the site files, not as root.
cd /home/username/public_html
wp core version
wp core update --minor
wp core update-db
wp core verify-checksums
wp core version--minor keeps the site on its current branch and only applies point releases. That is the right choice for a security rollout, and you can plan any move to a new major version separately. verify-checksums compares the core files against the official checksums. It is useful after any security release because it also catches modified core files left behind by an earlier compromise.
Many sites on one server
On cPanel servers or VPS hosts with many accounts, run a quick loop to see which sites are behind. This example assumes the usual cPanel layout and runs each command as the account owner:
for dir in /home/*/public_html; do
user=$(stat -c '%U' "$dir")
if [ -f "$dir/wp-config.php" ]; then
printf '%s: ' "$dir"
sudo -u "$user" -- wp --path="$dir" core version 2>/dev/null || echo 'check failed'
fi
doneA blank result or a “check failed” line still needs attention. It usually means a broken install, a PHP error or a permissions problem, which are often the same things that blocked the automatic update. Do not count those sites as finished.
A short update checklist
- Take a backup of files and database, or confirm last night’s backup completed and can be restored.
- Update to 7.1.3, or to the latest release in your branch if you are on an older supported version.
- Run
wp core verify-checksumsand look into any file it flags. - Go through user accounts. Several of these fixes involve Author-level and comment-level access, so remove accounts nobody uses and downgrade roles that have more access than they need.
- Clear the page cache, object cache and CDN cache so visitors get the fixed code.
- Check the comments screen and any pages with embeds to confirm they still display correctly.
- If a site still runs an old branch, plan its upgrade to 7.1. The release notes say only the latest version is actively supported, and backports are a safety net, not a long-term plan.
How TechProvidence can help
Keeping many WordPress sites patched is routine work, but it is easy to miss one. A site that quietly stopped auto-updating months ago is a common way into a server. TechProvidence offers managed WordPress hosting and maintenance, including scheduled core and plugin updates, version reporting across all your sites, file integrity checks, cPanel/WHM server management and help with upgrades from older WordPress branches. If you want someone to handle this for you, contact us.
Bottom line
WordPress 7.1.3 is a routine but important security release. Do not assume your sites updated themselves. Check the version on each one, verify core checksums, and use the update as a reason to remove user accounts and roles you no longer need.
Source: WordPress.org News
