WordPress 7.1.3: seven security fixes, and two of them are about comments

WordPress 7.1.3 came out on October 6, 2026, two weeks after 7.1.2. It fixes seven security issues and four bugs, and WordPress recommends updating immediately.

Two of the seven involve comments, and they're the two to read first. One let anyone read the approved comments on private and unpublished posts. The other is a stored cross-site scripting flaw on the Comments screen in WP Admin, which WordPress says can be exploited through a pending comment. Each of the other five needs something already in place first, such as an Author account or an administrator running an export.

What shipped

The release was led by Jake Spurlock. Between the 7.1.2 and 7.1.3 tags there are 18 commits: one for each of the seven security fixes, four bug fixes, three changes to WordPress's own test tooling, and four version bumps and tags.

The security patches are small. Together they add 119 lines and remove 103 across seven files, and most of that is existing code being moved or re-indented. The comments fix in class-wp-query.php, for example, moves a 37-line block further down the same function without changing a line of it.

Three of the seven are credited to Anthropic, which also reported two of the eleven in 7.1.1. The others came from Thomas Chauchefoin of Trail of Bits, Ananda Dhakal of Patchstack, the researchers Zhengyu Liu, Jingcheng Yang and Gavin Zhong, and Alex Concha of the WordPress security team.

When we checked on October 7, none of the seven had a CVE or a GitHub security advisory. 7.1.1's advisories were published the day after that release, so these may follow. Until then there's no severity score to sort by, and what an attacker needs first is the most useful guide.

WordPress's version documentation doesn't quite match the release. It says the release "features one security fix" and then lists seven. Its list of revised files also names two Customizer files that neither the source diff nor the built package touches, and leaves out the image metadata code and the toolbar stylesheet, which both change. The announcement and the diff agree on seven security fixes, and the About screen on four bug fixes.

The two that involve comments

Comments on private and unpublished posts, readable with no account

Reported by Ananda Dhakal of Patchstack. It's the only one of the seven that WordPress describes as unauthenticated.

Every post has its own comments feed. When WordPress built that feed for a single post, it fetched the comments before it checked whether the visitor was allowed to see the post. The check then hid the post, but by that point the comments were already loaded. So a logged-out visitor could read the approved comments on a private or unpublished post through its feed.

The fix moves the comment lookup below the visibility check, unchanged. If the visitor can't see the post, its comments are never fetched.

Only approved comments were exposed. The feed query only selects approved comments, and it already left out editorial Notes.

This matters most on sites that take posts private after they've collected comments: members-only posts, a retracted announcement, a client page pulled from the site. Until the update, those comments and their authors' names could be read by anyone through the feed.

Stored cross-site scripting on the Comments screen

Reported by Thomas Chauchefoin of Trail of Bits. WordPress describes it as a stored XSS on the Comments administration page, exploitable via pending comments, and hasn't published any more detail.

A pending comment is one waiting for moderation. On WordPress's default settings a visitor's first comment is held for approval, so on a site that accepts comments, anyone can create one without an account. The Comments screen is where an administrator or editor goes to approve it.

WordPress doesn't say which patch goes with which issue. By elimination, this one is the release's only change to admin JavaScript, in the code behind the Help tabs at the top of admin screens. It passed a link's address straight to jQuery, which will build HTML from a string that looks like HTML. It now looks the address up as a selector, which can't create elements.

We think this is the one to prioritise on sites that accept comments. The comment can come from a stranger, and the code would run in the browser of whoever moderates it.

The other five, sorted by what they need first

WordPress gives an access level for one of these and leaves the others unstated. Where it's unstated, we describe what the patched code now checks.

An Author account: making posts sticky

Reported by Anthropic. Sticky posts are pinned to the top of the blog's front page, and on WordPress's default roles that's an Editor's job. The REST API checked the two capabilities involved, edit_others_posts and publish_posts, but only refused a user who lacked both. Authors can publish their own posts, so they passed the check and could pin their posts to the top.

The check now requires both capabilities, which on the default roles means Editor or above. When an existing post is updated, the check only runs if the request changes the sticky setting, so an Author can still save a post that an Editor has already made sticky.

Someone embeds an Imgur link

Reported by Zhengyu Liu, Jingcheng Yang and Gavin Zhong. WordPress keeps a list of trusted embed providers, and it inserts their embed code into your pages as delivered. Embed code from anywhere else is filtered down to a short list of safe tags first. Imgur had been on the trusted list since WordPress 3.9.

The fix removes Imgur from the trusted list on every branch back to 4.7, so its embed code is no longer inserted unfiltered. Exploiting it needed an Imgur link embedded in a post or page. If your sites use Imgur embeds, look at one after updating.

An administrator runs an export: SQL injection

Reported by Anthropic. When you export content from Tools, then Export, and choose anything other than "All content" or Media, WordPress adds the attachments and featured images that belong to the posts you picked. It read the featured image IDs from post meta and later put them into an SQL query without forcing them to be numbers.

That makes it a second-order injection: the value is stored first and does its damage later, when an administrator runs an export. WordPress hasn't said what access it takes to store the value. The fix converts the IDs to integers at three points on the way to the query.

Unstated: hooks fired under crafted names

Reported by Alex Concha of the WordPress security team. Each time a post changes status, WordPress fires hooks whose names are built from the old status, the new status and the post type, such as draft_to_publish and publish_post. It built those names whether or not the status and post type were registered, so a crafted status or type could produce the name of an unrelated hook and set off whatever code listens for it.

From 7.1.3, those hooks only fire for registered statuses and post types. The general transition_post_status hook still fires for every change.

Unstated: a loop that could run forever

Reported by Anthropic. WP_Http::make_absolute_url() turns a relative link into a full URL, and part of it is a loop that strips ../ segments out of the path. Some paths contain ../ in a form the loop's pattern can't remove, and the loop kept trying, tying up a PHP process until something stopped it. The fix ends the loop when a pass removes nothing.

WordPress calls this function when it follows a redirect while fetching a remote URL, and when the block editor's link preview fetches a page's icon and image. In both cases the path comes from the remote server, so we think an attacker needs your site to fetch something from a server they control.

"I'm not on WordPress 7.1. Am I patched?"

Yes, once you take the update for your branch. You don't need to move to 7.1.

The version documentation doesn't include a backport table this time. The table below comes from two places that agree: WordPress's version API, which reports a new patch for every branch from 4.7 up, and each branch's backport commit in WordPress's source repository, which lists the fixes it carries. Every branch was tagged on October 6, the last about two hours after 7.1.3.

The version API now marks 7.1.2, 7.0.6, 6.9.9 and every other earlier patch as insecure. WordPress also repeats that only the most recent version is actively supported, and calls the older-branch fixes a courtesy.

"6 of 7" doesn't leave a hole

If you're on 6.4 or older, your branch took six of the seven fixes. The one it skipped is the export fix, and those branches don't have the code it changes. Adding attachments and featured images to a filtered export arrived in WordPress 6.5, and the 6.4.13 export code has no featured image lookup at all.

The other six reached every branch back to 4.7, so the patched version for your branch covers everything in this release that applies to it. Older branches still only get fixes as a courtesy, so plan the move off them.

The four bug fixes

7.1.2 was security-only. 7.1.3 also fixes four bugs:

• The toolbar's site icon could show at full size. 7.1 added your site icon to the admin toolbar, sized with a width and a height. A theme or plugin rule that overrides image sizes could make it render at the size of the image file. It's now held at 20 pixels square, or 28 on small screens.
• Image uploads on servers without PHP's DOM extension. Since 7.0, WordPress reads alt text embedded in an image's metadata when you upload it, and it used PHP's DOM extension to do that without checking it was installed. The extension is optional, so WordPress now checks first and skips the step if it's missing.
• ReverbNation embeds work again. ReverbNation moved its site and embed service to legacy.reverbnation.com. The old address returns a 404 and doesn't redirect, so artist and song embeds had stopped working. WordPress now uses the new address.
• Someecards embeds removed. Its embed service returns a 404 and its pages no longer advertise one, so it's been taken off the provider list.

With Imgur, that's three changes to embed providers in one release. If your sites embed a lot of third-party content, check a few pages after updating.

What to do

1. Update, or confirm the update has happened. Sites that take minor updates automatically should have it already. Check any site where a plugin or a wp-config.php constant turns them off.
2. Match the version to your branch. Dashboard, then Updates, shows what you're running. On 6.9, the patched version is 6.9.10.
3. Update before anyone works through the pending comments queue. If several people moderate, tell them.
4. Look at private and unpublished posts that have comments. If any of those comments hold something sensitive, treat it as readable until the moment you updated.
5. Check a page with an Imgur embed, if your sites use them.
6. Include staging and development copies. They have the same comment feeds and the same Comments screen as the live site.

If you're on Wordify

Automated Safe Updates applies a security release as soon as it's out, instead of holding it for your update window. The signal comes from WordPress: its version API now marks 7.1.2 and every superseded patch on the older branches as insecure, and that's what moves the update to the front of the queue. Sites with it switched on were patched within hours of the release.

Sites on older branches take their own branch's backport, so a site on 7.0 moves to 7.0.7 and a site on 6.9 moves to 6.9.10, with no major upgrade.

Before each update, Wordify takes a verified restore point. After it, Wordify loads the site and compares what comes back with what came back before. If that health check fails, the update is rolled back. Some sites always need a look by hand, and those land on your Tasks page.

If you'd rather not keep track of releases like this one yourself, here's what it looks like when Wordify does it for you, from switching it on to a rollback.