WordPress 7.1.3 Fixes Seven Security Issues

WordPress 7.1.3 was released on 6 October 2026, the third maintenance release in the 7.1 line in under three weeks. It carries seven security fixes and four bug fixes. Version 7.1.1 on 17 September fixed eleven security issues and 7.1.2 on 22 September closed a single critical hole, so a site that stopped updating in mid-September is now behind on all three. The release announcement recommends updating immediately.

The seven fixes

The announcement lists them without CVE numbers or per-issue severity, so the list below follows its wording:

• Stored cross-site scripting on the Comments administration page, exploitable through pending comments.
• A denial of service in the WP_Http::make_absolute_url() method.
• A second-order SQL injection in the WXR export.
• An authorisation weakness that let users with the Author role make posts sticky.
• Unauthenticated disclosure of comments on private and unpublished posts.
• Cross-site scripting in Imgur embeds.
• An action name collision caused by forgeable parameters passed to the {status}_{type} hook.

The one the announcement describes as unauthenticated is the comment disclosure. Comments on private and unpublished posts can contain material never meant to be public, so that exposure is a data leak rather than code execution. The stored script on the Comments screen is a different case: it is exploitable through pending comments, so the exposure is the administrator’s own screen.

Who found them

The announcement credits each report. The stored script on the Comments page was reported by Trail of Bits in collaboration with OpenAI. The denial of service, the SQL injection in the export and the Author sticky-post weakness were reported by Anthropic. The comment disclosure came from Ananda Dhakal of Patchstack, the Imgur issue from three researchers, and the hook name collision from a member of the WordPress security team. Four of the seven reports therefore involved AI laboratories, which is worth noting in the context of the automated security review now applied to plugin releases, where machine analysis is also doing the first pass.

What the announcement does not say

It gives no affected-version range for each fix. It says the security fixes are being backported to all branches eligible for security updates, currently through 4.7, and that the backports are in progress. It also notes that only the most recent WordPress version is actively supported. The practical reading is that a site on an older branch may receive a patched release later than a site on 7.1, and that the date of the backport matters more to that site than the date of 7.1.3.

The gaps between the three releases were five days and then fourteen. A site that updates on a weekly or fortnightly schedule could have stayed exposed to the 7.1.2 issue for up to the length of its own cycle, while the fix was public and probing had been observed. The length of the update cycle is, in effect, a decision about how long a published fix may stay unapplied, and it is worth making that decision on purpose.

Confirming a site has actually updated

Sites with automatic background updates will update on their own, according to the announcement. The sites that do not are the ones that matter: those where automatic updates were switched off, where a host pins the version, or where a staging workflow delays releases. Check three things:

1. The version shown under Dashboard, then Updates, reads 7.1.3 or a later release on the 7.1 branch.
2. The site responds normally after the update, in particular the front end and the Comments screen.
3. Any caching layer has been purged, so that what visitors receive was generated by the new code.

The 7.1.2 release is covered in the post on the path traversal that reached back to 4.7, where probing was observed within hours of the patch. That timing is the argument for treating a security release as a same-day task rather than a scheduled one. The earlier 7.1.1 announcement is the reference for the eleven fixes in the first release of the line.

A site manager responsible for several installations should record the version of each one after the update, not the intention to update. When a fourth release arrives in the 7.1 line, that list is what turns a patch cycle into a ten-minute job.