WordPress 7.1.3 Fixes Comment XSS and Private Post Leaks
WordPress 7.1.3 landed on 6 October 2026 as a maintenance and security release with seven security fixes and four bug fixes. It follows WordPress 7.1.2, which two weeks earlier fixed a single vulnerability tracked as CVE-2026-87902 that allowed an unauthenticated visitor to trigger a local file inclusion and, under the right PHP configuration, could lead to remote code execution. This release is a different kind: two of the fixes start with an unauthenticated visitor, the comment-feed leak and the comments XSS, which also needs a moderator to click. Three need a Contributor or Author account, one needs an administrator to run an export, and one is plugin-dependent hardening. Patchstack, the security firm that published the analysis, calls the update urgent but not a drop-everything emergency.
The most eye-catching fix is a stored cross-site scripting (XSS) flaw on the WordPress comments admin page. XSS lets an attacker put malicious code into a page that other people will later view. The Help tab click handler in `wp-admin/js/common.js` passed a link's href to jQuery's `$()`, which builds HTML from any string that looks like HTML. A link inside a pending comment can carry such an href. The handler only listens inside elements with 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; 7.1.0 added span class support for note mentions and trims it down on save. According to Patchstack's review, the pending-comment attack affects versions 7.1.0 through 7.1.2, and older backports harden the same code. The 7.1.3 fix replaces the behavior with `.find()`, which only reads selectors. The vulnerability was reported by Thomas Chauchefoin of Trail of Bits.
Two separate issues affect information disclosure. For single-post comment feeds, `WP_Query` loaded a post's comments before checking whether a visitor could see the post. The visibility check then cleared the post but not the comments, and because feeds never return a 404 status, the feed printed private or unpublished post comments to anyone. The fix moves the comment query after the visibility check; this was reported by Ananda Dhakal of Patchstack. In the Imgur case, WordPress normally runs HTML from untrusted oEmbed providers through a filter that reduces it to a sandboxed iframe. Imgur, however, sat on the trusted list, which skips that filter, so whatever came back from Imgur's API was output directly. That response includes text from the uploader's own image or album, so anything attacker-controlled landed on the page unfiltered. The fix removes Imgur as a trusted provider, so Imgur URLs are no longer embedded unfiltered. Notably, the update does not remove existing cached oEmbed content stored in `_oembed_*` post meta and `oembed_cache` posts, so an existing malicious embed keeps rendering until the site's cache is cleared. This issue was reported by Zhengyu Liu, Jingcheng Yang, and Gavin Zhong.
Several other fixes require a Contributor or higher account. A denial of service in `WP_Http::make_absolute_url()` came from a loop that collapses segment/../ pairs but never exits on a relative path like `a//../b`, because its regex matches nothing and the path never changes. A Contributor can trigger it through the block editor's link preview by pointing it at a page they control; 7.1.3 breaks the loop when a pass replaces nothing. A second-order SQL injection in the WXR export collected featured-image IDs straight from `_thumbnail_id` metadata and concatenated them into a query string without ensuring the ID was an integer. The fix adds `absint()` at three points. The vulnerable code only exists since WordPress 6.5.0 and is only reached when exporting a single content type; the default "All content" export does not touch it. Authors could also mark posts as sticky because the REST API refused a sticky request only when the user lacked both `edit_others_posts` and `publish_posts` capabilities. Authors have the `publish_posts` capability, so they passed; the fix changes the `&&` (and) to `||` (or). Both the denial of service and the SQL injection were reported by Anthropic.
The last fix is a hook name collision. WordPress builds some action names out of 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`. Unrelated actions follow the same naming pattern: `delete_post` fires when a post is deleted, and `comment_post` fires when a comment is added. Before 7.1.2, WordPress never checked that the status and post type were registered before building the name. A post saved with the status `delete` and the type `post` would fire `delete_post`, the same action as a real deletion, and every callback hooked to it would run as if a post had just been deleted. The fix only fires these hooks when the status and post type are registered. This was reported by Alex Concha of the WordPress Security Team.
WordPress 7.1.3 is available from the Dashboard under Updates or from WordPress.org, and sites with automatic background updates will pick it up on their own. The fixes have been backported to older branches through at least the 6.6 releases, but at the time of Patchstack's publication, branches 4.7 through 6.5 were yet to be patched. Patchstack also added the published vulnerabilities to its database on the same day. While updating, site owners should audit who holds Contributor or higher roles, because many of these fixes are about what those roles can reach. For site owners on managed WordPress hosting such as AEU Hosting, automatic core updates, staging environments, and security hardening make it easier to apply a release like 7.1.3, clear caches after patching, and review which accounts hold Contributor or higher roles before a pending comment ever reaches a moderator.