WordPress 7.1.3 fixes seven security vulnerabilities
WordPress 7.1.3 fixes seven security vulnerabilities and four software bugs in a maintenance and security release issued on 6 October 2026. The flaws include exposed comments on private content, two cross-site scripting routes, a denial of service, an export-related SQL injection issue, incorrect permissions for sticky posts and a collision between internal action names. The release deserves prompt installation, although the access and interaction required for most attacks mean it is not described as an immediate, drop-everything emergency.
This differs from WordPress 7.1.2, released two weeks earlier. That update fixed CVE-2026-87902, an issue that allowed an unauthenticated visitor, meaning someone without an account, to trigger local file inclusion and potentially make the server load an unintended local file. Under the right PHP configuration, it could lead to remote code execution, which means running commands on the server from elsewhere. In 7.1.3, two vulnerabilities begin with an unauthenticated visitor, three require a Contributor or Author account, one requires an administrator to run an export and one depends on how a plugin supplies post data.
One of the unauthenticated routes is stored cross-site scripting (XSS), in which hostile browser code is saved by a site and later delivered to another user. The Help tab handler in wp-admin/js/common.js passed a link's href value into jQuery's $() function, which can construct HTML when a string resembles HTML. An attacker could place such a link inside a pending comment, wrapped in an element using the contextual-help-tabs class. The attack still required an Editor or another moderator to click the link while reviewing the comment.
Visitor comments could not carry the required class before WordPress 7.1.0. That version introduced span class support for note mentions and reduced the value when saving it. Patchstack's code review therefore places the pending-comment attack window at versions 7.1.0 to 7.1.2. WordPress 7.1.3 replaces the risky operation with .find(), which interprets the supplied value only as a selector, a pattern for locating an existing page element. Older backported updates harden the same code.
A separate denial-of-service flaw affected WP_Http::make_absolute_url(). A denial of service makes a system unavailable or unresponsive. The function contained a loop intended to collapse path segments containing segment/../, but a relative path such as a//../b caused its matching rule to find nothing. Because the path remained unchanged, the loop never ended. A user with a Contributor account could reach the flaw through the block editor's link preview by linking to a page under that user's control. The fixed code stops looping when a pass makes no replacement.
The WXR export function also contained a second-order SQL injection issue. SQL injection is the insertion of manipulated data into a database command; second-order means the dangerous value is stored first and used later. WordPress took featured-image identifiers directly from _thumbnail_id metadata and joined them into a database query without first ensuring they were integers. Version 7.1.3 applies absint(), which converts a value to a non-negative integer, at three points. The vulnerable code has existed since 6.5.0 and is reached only when an administrator exports one content type. The default All content export does not use it.
Authors could also mark posts as sticky through the REST API, an interface through which software sends requests to WordPress. The permission check rejected a request only if the user lacked both edit_others_posts and publish_posts capabilities. Authors possess publish_posts, so they passed that test. The correction changes the logical condition from &&, meaning and, to ||, meaning or, so lacking either required permission is enough to stop the request.
The second unauthenticated issue exposed comments attached to private or unpublished posts. For a single-post comment feed, WP_Query fetched the comments before confirming that the visitor could view the post. WordPress then removed the post from the result but left its comments in place. Because feeds do not return a 404 response in this situation, the comments were printed. Version 7.1.3 performs the comment query only after the visibility check.
Another XSS flaw involved Imgur embeds. WordPress normally passes HTML from untrusted oEmbed providers through a filter that confines it to a sandboxed iframe, an isolated frame within the page. Imgur was on the trusted-provider list, so its API response bypassed that filter and was displayed directly. Those responses can contain text supplied by an image or album uploader, allowing attacker-controlled content to reach a page without filtering. The fix removes Imgur from the trusted list, meaning its URLs are no longer embedded without that protection. Exploitation requires a Contributor or higher account and a target who views the affected content.
Updating does not remove previously cached Imgur oEmbed material. Existing _oembed_* post metadata and oembed_cache posts can therefore continue displaying a malicious embed. Patchstack advises clearing the site's cache after installing the release so that this stored content does not keep rendering.
The final security change prevents action hook name collisions. Action hooks are named points where plugins can run their own code. When a post changes status, wp_transition_post_status() constructs a hook named from the new status and post type, so publishing a normal post produces publish_post. Other WordPress operations use similar names, including delete_post for deletion and comment_post when a comment is added.
WordPress 7.1.2 did not verify that the supplied status and post type were registered before constructing that name. A plugin passing raw data into wp_insert_post() could save a post with the status delete and type post, causing delete_post to run even though no real deletion had occurred. Every callback attached to that action would then behave as if a post had been deleted. WordPress 7.1.3 fires these dynamically constructed hooks only when both the status and post type are registered.
Credits for the seven fixes listed Trail of Bits, Anthropic, Patchstack, the WordPress Security Team and several individual researchers. WordPress 7.1.3 and backports through the 6.6 releases became available on 6 October, and Patchstack added the published vulnerabilities to its database that day. At the time of publication, branches 4.7 through 6.5 had not yet received patches.
Administrators can install WordPress 7.1.3 from Dashboard, then Updates, or obtain it from WordPress.org. Sites using automatic background updates should receive it automatically. Administrators should also review who holds Contributor, Author, Editor or higher roles because several of these flaws depend on the access those accounts provide.