WordPress Core 7.1.3 – Seven Security Fixes for XSS, SQL Injection, Data Exposure, and DoS

WordPress 7.1.3 is a maintenance and security release containing seven security fixes and four bug fixes. WordPress.org recommends updating immediately. The release addresses stored cross-site scripting, unauthenticated comment disclosure, second-order SQL injection, denial of service, authorization weakness, unsafe oEmbed handling, and a dynamic-hook collision.

Release summary

Security issues fixed in WordPress 7.1.3

1. Stored XSS in comment moderation

A pending comment could contain a specially structured link that reaches a vulnerable click handler in the Comments administration screen. JavaScript execution still requires an Editor-or-higher user to click the crafted link while reviewing the comment. Patchstack’s code review indicates that the directly affected current branch is WordPress 7.1.0 through 7.1.2; older backports harden the same code path.

2. Unauthenticated disclosure of private-post comments

A single-post comment feed could query comments before WordPress verified whether the visitor was allowed to view the associated post. Clearing the inaccessible post object did not clear the already loaded comments, allowing an unauthenticated visitor to retrieve comments associated with private or unpublished content.

3. Second-order SQL injection in WXR export

The single-content-type WXR export path concatenated featured-image IDs from _thumbnail_id metadata into a query without first converting them to integers. Exploitation requires a malicious value to already exist in the database and an administrator to run the affected export. WordPress 7.1.3 applies absint() before those IDs reach the query.

4. Denial of service in WP_Http URL normalization

A malformed relative URL could keep WP_Http::make_absolute_url() in a loop. A Contributor-level user could reach the code through block-editor link previews pointing at an attacker-controlled page. The fix stops processing when a normalization pass makes no progress.

5. Authors could make posts sticky

The REST API capability condition allowed Authors to set the sticky flag because it denied the request only when both required capabilities were absent. The corrected check requires the proper capability combination.

6. Imgur oEmbed XSS

Imgur was treated as a trusted oEmbed provider, so returned HTML could bypass the sandboxing applied to untrusted providers. WordPress 7.1.3 removes Imgur from the trusted-provider list. Existing cached oEmbed records are not automatically removed, so potentially unsafe cached content may continue rendering until reviewed or cleared.

7. Dynamic status/type hook collision

WordPress built transition-hook names from status and post-type values without first confirming that both values were registered. Crafted values could collide with unrelated core action names. The release limits these dynamic hooks to registered statuses and post types.

Immediate remediation

1. Update WordPress Core to 7.1.3 or the newest security release available for the site’s maintained branch.
2. Confirm the update completed and verify core checksums.
3. Purge page, object, and CDN caches after the update.
4. Review pending comments before clicking links inside comment content.
5. Audit Contributor, Author, Editor, and Administrator accounts and remove access that is no longer required.
6. Review cached Imgur oEmbeds if the site has embedded attacker-controlled or untrusted Imgur content.

WP-CLI verification

wp core version
wp core check-update
wp core verify-checksums

For the current 7.1 branch, wp core version should report 7.1.3 or later. Sites pinned to an older maintained branch should install the corresponding backport once WordPress.org makes it available.

Review cached oEmbed content

Before deleting anything, inventory cached oEmbed posts and metadata:

wp post list --post_type=oembed_cache --fields=ID,post_title,post_date --format=table
wp db query "SELECT post_id, meta_key, LEFT(meta_value, 200) AS preview FROM wp_postmeta WHERE meta_key LIKE '\\_oembed\\_%' ORDER BY post_id DESC LIMIT 200;"

If your database uses a prefix other than wp_, substitute the correct prefix in the SQL query. This is a review step, not an instruction to delete every oEmbed cache entry. Investigate entries tied to untrusted Imgur URLs, preserve evidence where compromise is suspected, and clear affected cache records through normal WordPress tooling.

Backport note

WordPress.org says security backports are being prepared for all eligible branches through 4.7. At publication time, Patchstack reported that backports had reached at least the 6.6 branch while older branches were still in progress. Running the latest actively supported WordPress release remains the safest option.

Sources

• WordPress.org: WordPress 7.1.3 Maintenance and Security Release
• Patchstack: technical analysis of the seven fixes
• WordPress Trac: 6.6 security backport changeset

WPDeeply did not discover these vulnerabilities. This advisory summarizes the official WordPress release and Patchstack’s public technical analysis.