WordPress 7.1.3 Patches Seven Security Flaws

This is the third security release on the 7.1 branch in under three weeks. WordPress 7.1.1 patched 11 security flaws on 17 September, and five days later WordPress 7.1.2 fixed a critical remote code execution flaw. Version 7.1.3 covers more ground than 7.1.2, with fixes spread across comments, the REST API, the export tool, embeds, outbound requests and post status hooks. But the release note gives no severity rating for any of the seven, and most need a logged-in account or a particular feature in use before they matter.

Two of them need no login at all. A stored cross-site scripting flaw on the Comments screen can be planted through a comment awaiting moderation, which on a site that accepts comments from visitors anyone can submit. A separate flaw let visitors who were not logged in read comments left on private and unpublished posts. Those two are the reason to confirm the update has landed today.

How the fixes work

The release note gives each fix a single line, and no GitHub advisories or severity scores had been published at the time of writing, so the clearest picture comes from the note read alongside the security commits merged into the 7.1 branch on 6 October. In plain English:

• Stored XSS on the Comments screen. Reported by Thomas Chauchefoin of Trail of Bits. The release note says it was exploitable via pending comments, so a malicious comment sitting in the moderation queue could run script in the browser of whoever opened the Comments screen in the dashboard.
• Comments on private and unpublished posts. Reported by Ananda Dhakal of Patchstack. WordPress builds a comments feed for each individual post, and it was loading that post's approved comments before checking whether the visitor was allowed to see the post. The fix moves the comment query after the visibility check, so the feed for a private post or a draft no longer returns its comments.
• Authors could make posts sticky. Reported by Anthropic. A sticky post is pinned to the top of the main blog listing. Through the REST API, which the block editor uses, WordPress only refused a sticky request when the user had neither the right to edit other people's posts nor the right to publish. Authors can publish, so their requests went through. Both rights are now required, which in a default install means Editor or above.
• SQL injection through the export tool. Reported by Anthropic. When someone runs Tools > Export to produce a WXR file, WordPress gathered featured image IDs from post metadata and placed them in a database query without forcing them to be whole numbers. The commit describes this as "second-order SQL injection via user-controlled meta values": a value planted earlier by a lower-privileged user would only be executed later, inside an administrator's export. The IDs are now cast to integers before they reach the query.
• A denial of service in outbound requests. Reported by Anthropic. WP_Http::make_absolute_url() turns a relative web address into a full one, and WordPress calls it when following a redirect during an outbound HTTP request. A crafted path could leave its clean-up loop running without end, tying up the server process handling the request. The loop now stops as soon as there is nothing left to remove.
• Cross-site scripting through Imgur embeds. Reported by Zhengyu Liu, Jingcheng Yang and Gavin Zhong. Rather than patch the Imgur handling, WordPress has removed Imgur from its built-in list of trusted embed providers, and the code now records it as removed in 7.1.3.
• Forgeable status transition hooks. Reported by Alex Concha of the WordPress security team. When a post changes status, WordPress fires actions whose names are built from the statuses and post type involved, such as draft_to_publish and publish_post. Crafted values could produce a name that collides with an unrelated action. Those dynamic hooks now fire only when the statuses and post type are registered.

The four bug fixes are smaller. The image alt text reading added in 7.0 now checks the PHP DOM extension is installed before using it, the toolbar site icon added in 7.1 keeps its size when a stylesheet resizes images globally, the ReverbNation embed points at the service's new address, and Someecards has been dropped from the embed list because its endpoint no longer works.

Examples and use cases

A membership site, a staff intranet or a client portal built on WordPress is the clearest case for the comment disclosure. Content there is often private or in draft, and its comments can carry names, internal discussion or customer details. Before 7.1.3, the comment feed for a private or draft post would return its approved comments to a visitor who was not logged in. A brochure site with no private content and comments switched off had nothing to leak.

A multi-author blog, or a news site with freelance contributors, is where the sticky and export fixes matter. An Author account exists to publish its own work, not to decide what leads the blog, yet before the fix an Author could make a post sticky through the REST API, by mistake, for self-promotion or because the account had been compromised. On the same kind of site, a business that exports its content for a migration or backup gave a lower-privileged user a route to get a database query run inside the administrator's export.

The Comments screen flaw has the widest reach. Any site that holds comments for moderation lets an outsider put content in front of the person who moderates. That person is usually an administrator or editor, and cross-site scripting that runs in their browser session acts with their permissions. Sites with comments switched off and an empty moderation queue had no route in.

Imgur is the change most likely to be visible: a content team that pastes Imgur links into posts will find WordPress no longer treats them as a trusted embed.

What this means for UK site owners

Most sites should already be on 7.1.3. Minor and security releases have installed themselves through automatic background updates by default since WordPress 3.7. The cases that need a person are the familiar ones: WP_AUTO_UPDATE_CORE set to false, a host that holds core updates back to apply on its own schedule, a version pinned in a Composer lockfile, or a file permissions problem that has quietly stopped updates working. The quickest check is the version number under Dashboard > Updates. Sites still on older branches have their own patched versions, dated 6 October in the WordPress release archive, including 7.0.7, 6.9.10, 6.8.11 and 4.7.38 on the oldest branch still receiving fixes.

For UK businesses there are two further reasons to confirm the update rather than assume it. The first is Cyber Essentials. The scheme's Requirements for IT Infrastructure v3.3, in effect since 27 April 2026, ask for updates to be installed within 14 days of release where they fix vulnerabilities the vendor rates as critical or high risk, and also where the vendor gives no details of the severity at all. The 7.1.3 release note rates none of its seven fixes, so on that wording it falls inside the 14-day rule, which runs to 20 October. The requirements bring publicly available commercial web applications into scope by default and leave bespoke components out, so check with your certification body how your website is scoped before treating it as covered or exempt.

The second is data protection. The comment disclosure exposed whatever had been written in comments on private and draft posts, and on a client portal or intranet that can include personal data. The ICO's guide to data security explains the UK GDPR's security principle, which requires "appropriate technical and organisational measures", and applying a published security fix promptly is about as basic as those measures get. If a site you run held sensitive discussion in comments on private posts, check the access logs for requests to those posts' comment feeds from before the update landed.

Three security releases in three weeks is a fair test of whether updates are being watched or simply hoped for. If nobody is checking the version number, the moderation queue and the user list, our WordPress maintenance packages cover tested core and plugin updates, daily backups and security monitoring for UK sites.

Practical considerations

Two of the fixes change behaviour that plugins may rely on. The status-specific hooks, such as draft_to_publish and the {new_status}_{post_type} family, now fire only when WordPress recognises the statuses and post type involved, while the general transition_post_status action fires as before. A plugin that uses a custom post status without registering it through register_post_status() may find notifications, cache clears or syncs tied to that status no longer run. On the REST side, an Author is only refused when trying to change a post's sticky setting, so editing a post that is already sticky still works.

Check how existing posts with Imgur embeds display after the update, and replace anything that now shows as a bare link with an image uploaded to your own media library, which also removes the dependency on a third-party host. Fuller detail may still follow, as the GitHub advisories for 7.1.1 appeared the day after that release. Finally, two of these fixes start with a lower-privileged account, so review who holds Author and Contributor access, remove accounts that are no longer used, and match each person to the roles and capabilities they actually need.

FAQ