WordPress 7.1.3 security update fixes seven Core issues

WordPress 7.1.3 addresses seven security issues in Core, including stored XSS, second-order SQL injection, denial of service, private-comment disclosure, and authorization flaws. The public Core diff shows a set of small, targeted patches rather than a broad feature release.

What WordPress 7.1.3 fixes

The official WordPress 7.1.3 release documentation lists seven security issues. They affect several different areas of Core rather than one shared subsystem.

The release page contains singular wording in one introductory sentence, but it then enumerates these seven separate security issues. For practical purposes, site owners should treat 7.1.3 as a multi-fix Core security release.

What the public WordPress Core diff shows

We also compared the official WordPress 7.1.2 and 7.1.3 tags in the public wordpress-develop repository. The compare contains 18 commits overall, including release housekeeping and test/build changes, while the security-related commits line up closely with the seven issues listed above.

WXR export now forces post IDs to integers

The export patch adds absint() sanitization to thumbnail IDs and again to IDs immediately before they are interpolated into the WXR export query.

The Core comment is unusually explicit: the first cast is there to prevent second-order SQL injection through user-controlled meta values, with a second sanitization pass immediately before SQL construction as defense in depth.

The REST API sticky-post permission check was tightened

The sticky-status patch changes the authorization logic so a user must satisfy both required capabilities before changing sticky status. It also checks whether an update is actually trying to change the current sticky state.

This closes the gap that could let an Author-level user perform an action that should require higher privileges.

Comment feeds are built only after post visibility is checked

In WP_Query, the block that builds a singular post's comment feed was moved until after WordPress determines whether the post itself is viewable.

That ordering change is important: WordPress no longer prepares the associated comments before completing the private/unpublished-post visibility checks.

The HTTP path-normalization loop now has a progress guard

In WP_Http::make_absolute_url(), WordPress previously repeated a regular-expression replacement while resolving ../ path segments.

WordPress 7.1.3 now records how many replacements were made and breaks out if a pass makes no progress. That prevents a malformed path from keeping the normalization loop running indefinitely.

Imgur was removed from the built-in oEmbed allow list

The Imgur security fix is particularly clear in the diff: WordPress removes the Imgur provider pattern and its oEmbed endpoint from WP_oEmbed.

The provider history table now marks Imgur support as ending in WordPress 7.1.3. Existing Imgur links can still be handled as normal links, but WordPress no longer treats Imgur as a trusted built-in oEmbed provider.

Dynamic post-status hooks now require registered values

WordPress builds several post-transition hook names dynamically from values such as the old status, new status, and post type.

The 7.1.3 patch checks that the relevant statuses and post type are registered before firing those dynamic hooks. This prevents forged values from being turned directly into unintended action names.

Administration-side selector handling was hardened

The administration JavaScript changes contextual-help navigation from passing a link's href directly into jQuery's $() constructor to finding that selector explicitly inside the existing document.

It is a one-line patch, but it narrows what the string is allowed to mean. Instead of letting jQuery interpret the value more broadly, WordPress treats it as a selector for an existing element in the current page.

Does this mean every unpatched site is compromised?

No. A security release tells us that vulnerable code existed and has now been patched. It does not prove that every site running an affected version was attacked or that every issue is exploitable under identical conditions.

Several fixes also require specific contexts: a lower-privileged authenticated user, a particular export workflow, comment-feed access, or processing of a specific type of input.

That context is useful when assessing an incident, but it is not a good reason to postpone the update. These are Core issues, and the supported fix is already available.

What site owners should do now

1. Confirm the current WordPress version. Do not assume an automatic background update has already completed.
2. Take or confirm a recent backup. On transactional sites, make sure the database is covered as well as files.
3. Install WordPress 7.1.3 or the appropriate patched release for the branch you intentionally maintain.
4. Verify wp-admin and the frontend. Check editing, forms, login flows, search, comments where relevant, and any custom functionality.
5. For WooCommerce, test the transaction path. Verify cart, checkout, payment, order creation, emails, subscriptions, and critical integrations where applicable.

This comes shortly after the WordPress 7.1.2 security release, so sites that were patched after the September 22 update should be checked again rather than assuming they are still current.

Do you need a compromise investigation?

Running an affected version is not by itself evidence of compromise. For a site with no suspicious behavior, the first job is to patch and verify normal operation.

A deeper review becomes appropriate when there are actual warning signs: unfamiliar administrator accounts, changed PHP files, redirects, spam pages, hosting malware alerts, unexplained scheduled tasks, altered configuration, or other unexpected behavior.

Our guide to checking whether WordPress has been hacked covers the first-pass indicators. Updating Core closes the known patched paths, but it does not remove persistence from a site that was already compromised.

The practical takeaway

WordPress 7.1.3 is not a feature update. Its important changes are narrow security patches around sanitization, authorization, post visibility, path handling, embeds, dynamic hooks, and administration-side input handling.

The public Git history supports the same conclusion as the release notes: this is an update to install promptly, followed by a normal production verification pass.

FAQ