WordPress 7.1.3 Security Release: What the 7 Fixes Mean for Your Site

WordPress 7.1.3 came out on October 6, 2026. It fixes seven security issues and four bugs, and WordPress.org asks everyone to update right away. This article explains what each fix does, who could have used the flaw, how to tell whether your site is exposed, and how to update and check the result.

The release has a different shape from the last one. WordPress 7.1.2, two weeks earlier, fixed a single serious flaw that an unauthenticated visitor could reach. 7.1.3 is a set of smaller problems. Most of them need an account on your site, an administrator doing something specific, or a particular plugin setup. That changes how you triage the update, not whether you install it.

TL;DR

• WordPress 7.1.3 shipped on October 6, 2026 with 7 security fixes and 4 bug fixes. Update from Dashboard > Updates, or let automatic background updates do it on sites that support them.
• Two fixes start with a visitor who has no account: comments on private posts showing up in comment feeds, and a stored XSS on the Comments admin screen that also needs a moderator to click a link.
• Three fixes need a Contributor or Author account. One needs an administrator to run a single-content-type export. One only matters if a plugin passes raw post status or post type values into wp_insert_post().
• The announcement lists no CVE numbers. WordPress.org says to update immediately. Patchstack's analysis calls it important but not an emergency. Update the same day if you run a multi-author site or a busy comment queue.
• After updating, clear your caches and review who holds Contributor or higher roles. A cached malicious Imgur embed keeps rendering after the patch.
• Older branches are getting backports, and some had not shipped when Patchstack published. Only the latest WordPress version is actively supported.

What is in WordPress 7.1.3?

The official announcement describes it as a maintenance and security release with seven security fixes and four bug fixes, led by Jake Spurlock. It was published on October 6, 2026. The four bug fixes are listed only as tickets in the 7.1.3 milestone on WordPress Trac, so this article does not describe them. If one of your plugins or themes behaves differently after the update, that ticket list is the place to look.

The seven security fixes are below. The "who can trigger it" column comes from Patchstack's review of the code changes, and the reporters come from the WordPress.org announcement.

The release announcement does not assign CVE numbers to any of these. If your scanner or compliance tooling needs identifiers, they may appear later in vulnerability databases, so treat any ID you see today as something to verify against the source.

How serious is WordPress 7.1.3 for your site?

Sort the fixes by what an attacker needs before they can do anything. That is the fastest way to decide how hard to push the update.

Two fixes start from the outside. Anyone on the internet can read the leaked comments, and anyone who can leave a comment can plant the XSS payload. Both still depend on your configuration, though. The comment leak only matters if you have comments attached to private or unpublished posts. The XSS only fires if a moderator clicks a link inside a pending comment.

Three fixes need a logged-in account at Contributor or Author level. That sounds safe until you count the accounts. Multi-author blogs, membership sites that grant Contributor on sign-up, and agencies that leave old freelancer accounts active all have more of these than the owner expects.

One fix needs an administrator to run a particular export against data that is already bad. One is a hardening change that only touches sites running plugins that handle post status and type loosely.

Patchstack's own read is that you should update as soon as you can, but that this is not a drop-everything emergency. WordPress.org's wording is stronger and tells you to update immediately. Both can be true. If you manage one small site with no public sign-up, the risk is low and updating takes a minute. If you manage dozens of sites with open registration, the same release deserves a same-day rollout.

What each fix does

Stored XSS on the Comments admin page

This one is a chain. A click handler for the admin Help tab in wp-admin/js/common.js passed a link's href value to jQuery's $() function. That function builds HTML from any string that looks like HTML. A link inside a pending comment can carry such an href, but the handler only listens inside elements that have the class contextual-help-tabs, so the link also needs a wrapper with that class.

Before WordPress 7.1.0, visitor comments could not carry a class attribute. Version 7.1.0 added span class support for note mentions, and the code trims it down on save. According to Patchstack's review, the pending-comment attack affects 7.1.0 through 7.1.2, and older branches get a backport that hardens the same code. The fix in 7.1.3 uses .find(), which only reads selectors and does not build HTML.

The practical risk is a script running in a moderator's logged-in session. Until you update, a sensible precaution is to avoid clicking links inside comments in the pending queue. That is general caution, not something the sources prescribe.

This is a separate bug from Comment2Shell, a different comment-based flaw that was fixed in 7.1.1. If you updated for that one, you still need 7.1.3 for this one.

Denial of service in WP_Http::make_absolute_url()

WordPress has a loop that collapses segment/../ pairs in a URL path. On a relative path such as a//../b, the pattern matches nothing, the path never changes, and the loop never exits. A Contributor can reach this through the block editor's link preview by pointing it at a page they control.

An endless loop ties up a PHP process. How long it holds on and how much damage it does depends on your PHP time limits and how many workers your host gives you, which the sources do not cover. The fix in 7.1.3 breaks out of the loop when a pass replaces nothing.

Second-order SQL injection in WXR export

"Second-order" means the bad value is stored first and does damage later. The export code collected featured-image IDs straight from _thumbnail_id post metadata and concatenated them into a query without forcing them to be integers. 7.1.3 adds absint() at three points.

The conditions are narrow. The vulnerable code has only existed since WordPress 6.5.0. It is only reached when you export a single content type, and the default "All content" export does not touch it. It also needs a bad _thumbnail_id value to already be in your database, and an administrator to run the export. Most sites will never meet all of that, but a site that imports content from untrusted sources is the one to think about.

Author role users able to sticky posts

The REST API refused a sticky request only when the user lacked both the edit_others_posts and publish_posts capabilities. Authors have publish_posts, so they passed the check. The fix changes the logic from "and" to "or".

In plain terms, an Author could pin a post to the top of your front page, which is a decision that belongs to editors. The impact is about content control, not data theft, and it is the lowest-risk item here for most sites. It still matters on a publication where editors decide what leads.

Comments on private and unpublished posts exposed

For single-post comment feeds, WordPress loaded the post's comments before it checked whether the visitor was allowed to see the post. The check then cleared the post but not the comments. Because feeds never return a 404, the feed printed the comments anyway. The fix moves the comment query after the visibility check.

This is the one with no account requirement. If you have comments on private or unpublished posts, those comments could be read by anyone who requested the right feed. The sources do not say how long the behavior existed or that anyone abused it.

XSS through Imgur embeds

WordPress runs HTML from untrusted oEmbed providers through a filter that reduces it to a sandboxed iframe. Imgur was on the trusted list, which skips that filter, so whatever Imgur's API returned was output directly. That response includes text from the uploader's own image or album, so anything an attacker controlled in it landed on your page unfiltered.

The fix removes Imgur from the trusted list. The sources do not say how Imgur embeds will look afterwards, so check any page where you embed Imgur content. One more point matters a lot: updating does not remove existing cached oEmbed content. A malicious embed that is already stored keeps rendering until the cache is cleared. The commands for that are in the checklist below.

{status}_{type} hook name collision

WordPress builds some action names from a post's own data. When a post changes status, wp_transition_post_status() fires {new_status}_{post_type}, so publishing a post fires publish_post. The trouble is that unrelated actions follow the same pattern. delete_post fires when a post is deleted, and comment_post fires when a comment is added.

Before 7.1.3, WordPress did not check that the status and post type were registered before building the name. A post saved with the status delete and the type post fired delete_post, and every callback hooked to it ran as if a post had just been deleted. The fix only fires these hooks when both values are registered.

The risk is limited to plugins that pass a raw status or post type from user input into wp_insert_post(). If you write plugins, validate those values yourself instead of relying on the core change:

$allowed_statuses = array( 'draft', 'pending', 'publish' );
$status = isset( $_POST['status'] ) ? sanitize_key( wp_unslash( $_POST['status'] ) ) : 'draft';

if ( ! in_array( $status, $allowed_statuses, true ) ) {
	$status = 'draft';
}

$post_type = isset( $_POST['type'] ) ? sanitize_key( wp_unslash( $_POST['type'] ) ) : 'post';

if ( ! post_type_exists( $post_type ) ) {
	$post_type = 'post';
}

An allowlist of the statuses your plugin actually expects is stronger than checking whether a value is registered, because it also blocks real statuses you never meant to offer.

How to update to WordPress 7.1.3

Take a backup first. On MagicWP you can create an on-demand backup before the change, and the backup docs cover restoring one. Then pick the path that fits how you run the site.

From the dashboard. Open Dashboard > Updates and click Update Now. This is the path WordPress.org recommends in the announcement.

With WP-CLI. Run these from the site's directory over SSH:

wp core version
wp core update --version=7.1.3
wp core verify-checksums

The first command shows what you are running. The second updates to the exact release instead of "whatever is latest". The third compares your core files against the checksums published by WordPress.org, which is a quick check that the update landed cleanly and nothing in core was altered.

If your site is on an older branch, such as 6.8.x, add --minor instead of --version, so WordPress stays on that branch and only takes the newest maintenance release:

wp core update --minor

Automatically. The announcement says sites that support automatic background updates will start the update on their own. By default, existing installs receive minor core updates, which includes security releases like this one. Installs created on WordPress 5.6 or later also receive major updates by default, unless WordPress detects a version control checkout.

Automatic updates stop working if someone has changed the settings. Check wp-config.php for these:

define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', false );

Either line turns core auto-updates off. A value of 'minor' for WP_AUTO_UPDATE_CORE keeps minor updates on, which is what you want for a site you do not want jumping to a new major version. Do not assume a site updated itself. Look at the version number.

MagicWP includes automatic core updates with rollback, but confirm the version shown for each site instead of assuming it has already moved. Our security page lists what the platform does for you.

What to check after you update

Updating closes the holes, but a few things are left over from before the patch.

1. Clear cached oEmbed data. The documented WP-CLI command clears the oEmbed cache stored in a post's metadata:

   terminal

   wp embed cache clear 123

   To run it across posts and pages, loop over their IDs:

   terminal

   for id in $(wp post list --post_type=post,page --format=ids); do
     wp embed cache clear "$id"
   done

   Add any custom post types where you embed media. Patchstack also notes that cached embeds live in oembed_cache posts. Count them first, and take a backup before deleting anything:

   terminal

   wp post list --post_type=oembed_cache --format=count

   These are cache entries, so removing them forces a fresh fetch the next time the embed is needed.

2. Clear your page cache and CDN cache. A cached page can keep serving a bad embed whether or not WordPress itself is fixed.

3. Audit Contributor, Author, and higher roles. Patchstack's advice is to review who holds these roles, because many of these fixes are about what those roles can reach. List them with:

   terminal

   wp user list --role=contributor --fields=ID,user_login,user_registered,roles
   wp user list --role=author --fields=ID,user_login,user_registered,roles

   Remove accounts you do not recognize, and downgrade accounts that no longer need the access.

4. Look through the pending comment queue. List what is waiting for moderation, and look for links you do not expect:

   terminal

   wp comment list --status=hold --fields=comment_ID,comment_author,comment_author_email,comment_date,comment_content

5. Review comment feed requests if you hold private content. If you have private posts with comments, search your access logs for requests to comment feeds. A log entry only shows that a feed was requested, not that anything leaked, and none of the sources report abuse, so treat this as due diligence, not an incident.

If you missed the last point release, our write-up of the WordPress 7.1.1 security fixes covers that set, and the backup and restore guide explains how to test a restore so you know it works before you need it.

What about older WordPress versions?

The announcement says the security fixes are being backported, where necessary, to all branches eligible for security fixes, currently through 4.7. It also says that only the most recent version of WordPress is actively supported, and that the backports are in progress and will ship as they become ready.

Patchstack's article gave a more specific picture on October 6: backports had shipped through the 6.6 branch, while branches 4.7 through 6.5 were still waiting. That status was moving when it was written, so check the WordPress release archive for your branch before you decide to wait. If you are on a branch that has not received its patch yet, moving to the current 7.1 release is the cleaner fix. A backport arrives later and covers less.

Frequently Asked Questions

Is WordPress 7.1.3 a critical security update?

WordPress.org says to update immediately, and the release has seven security fixes. The release notes do not assign severity ratings or CVE numbers. Patchstack's analysis says it is worth updating as soon as you can but is not a drop-everything emergency, because most fixes need an account, an admin action, or a specific plugin. Treat it as same-day for sites with many contributors, open comments, or private content with comments, and as routine-but-prompt for small single-author sites.

Do I need WordPress 7.1.3 if I am still on 7.1.1 or 7.1.2?

Yes. 7.1.3 is the current release and it contains the fixes for everything listed above. Version 7.1.2 only fixed one issue, and 7.1.1 fixed a different set. Patchstack's review says the Comments screen XSS affects 7.1.0 through 7.1.2, so none of those versions is covered. Updating from either is a small maintenance step, not a major upgrade, and it should take only a few minutes on most sites.

Will my site update to 7.1.3 automatically?

Probably, but check. The announcement says sites that support automatic background updates will start the update on their own. Existing installs get minor core updates by default, and this is a minor release. The update will not happen if AUTOMATIC_UPDATER_DISABLED is set to true, if WP_AUTO_UPDATE_CORE is set to false, or if filters or a host-level rule block it. Look at the version in the dashboard rather than assuming.

Has anyone exploited these vulnerabilities?

The WordPress.org announcement and Patchstack's analysis do not report active exploitation as of October 7, 2026. That can change quickly after a patch is public, because the code diffs show exactly what was wrong. Do not treat the lack of reports as a reason to wait. Check the Patchstack vulnerability database and the WordPress.org news page for updates, and treat anything you read after this date as newer than this article.

Does updating remove malicious Imgur embeds that are already on my site?

No. The patch stops Imgur content from being treated as trusted going forward, but it does not delete embed data that is already cached. Patchstack notes that cached oEmbed content in post metadata and oembed_cache posts keeps rendering, so an existing malicious embed stays live until the cache is cleared. Clear the oEmbed cache with wp embed cache clear, then clear your page cache and CDN cache.

What do the four bug fixes in 7.1.3 change?

The announcement links to a Trac query for the 7.1.3 milestone but does not describe the four bug fixes in prose. The details were not available in the sources reviewed for this article, so they are not described here. If you see unexpected behavior in the editor, admin, or front end after updating, read the closed tickets in that milestone. This is also the kind of detail that changes after publication, so confirm it against WordPress Trac.

Do I need to worry about the WXR export bug if I never export my site?

Probably not. The SQL injection needs an administrator to run an export, a single content type selected instead of the default "All content" option, and a bad _thumbnail_id value already in your database. The vulnerable code has existed since WordPress 6.5.0. You are mainly at risk if you have imported content from untrusted sources and later run targeted exports. Updating removes the problem regardless, so you do not need to inspect your data first.

Conclusion

By Patchstack's assessment, WordPress 7.1.3 is not the same kind of emergency as 7.1.2, but it is still a security release and you should install it. Seven fixes, three of them reported by Anthropic, close paths that range from a leaked comment feed to stored XSS in the moderator screen. Update from the dashboard or with WP-CLI, confirm the version, then clear your oEmbed and page caches and review who holds Contributor or Author roles.

If you would rather not track every point release by hand, MagicWP applies automatic core updates with rollback and keeps daily off-site backups, so a bad update is a restore instead of a long night. You can read more on the managed WordPress hosting page, and it is worth confirming each site's version in the dashboard either way.