WordPress 7.1.3: Seven Security Fixes, and How to Confirm Your Live Sites Have Them

WordPress 7.1.3 shipped on October 6, 2026 with seven security fixes and four bug fixes. Patchstack’s review says two of the seven start with a visitor who is not logged in. One of those is a stored XSS in the Comments admin screen, and Pantheon put a platform-wide virtual patch in front of it. Pantheon still tells customers to update.

This piece covers what the seven fixes are, who can reach each one, which older branches got the same fixes, and why a release from three weeks ago may still be missing from some live sites. It ends with a checklist for agencies that manage many client sites.

The short version: check the version on the live environment of every site, not on dev or in your repository. On hosts that disable WordPress auto-updates, such as Pantheon, an update applied to Dev is not on Live until someone deploys it. After updating, clear caches and look through the pending comment queue before anyone clicks a link in it.

Facts below are as of October 20, 2026, from the WordPress.org announcement, the WordPress version page, Patchstack and Pantheon’s release note.

What WordPress 7.1.3 fixes

The WordPress 7.1.3 announcement lists seven security fixes. Jake Spurlock led the release. The announcement says: "Because this is a security release, it is recommended that you update your sites immediately."

No CVE numbers appear on the announcement or on the WordPress 7.1.3 version page. Patchstack’s article does not list any either. Neither WordPress nor Patchstack published severity scores for these fixes.

The table uses Patchstack’s description of what an attacker needs for each one.

The two fixes an unauthenticated visitor can start

Patchstack’s review, by researcher Chazz Wolcott, puts it this way: "Two fixes start with an unauthenticated visitor: the comment-feed leak, and the comments XSS."

The comment leak. Patchstack traces it to comment feeds. For a single post’s comment feed, WordPress loaded the comments before checking whether the visitor could see the post. Comments on private or unpublished posts could show up in the feed. No login is needed.

The comments XSS. Anyone who can leave a comment can plant it. It fires only when a moderator, Editor or higher, clicks a link in the pending comment. Patchstack says the pending-comment attack affects 7.1.0 through 7.1.2.

Patchstack’s overall tone is measured. Its article says to "Update as soon as you can," and also that "this isn’t a drop-everything emergency." The other five fixes need a logged-in account with some role, an administrator action, or a specific plugin.

That matters for association and nonprofit sites. Many of them have open comments, and staff who moderate them every day.

What Pantheon’s virtual patch does, and does not do

Pantheon’s WordPress 7.1.3 release note says it deployed a platform-wide mitigation, "virtual patching via our routing network." The rule targets external abuse of the Comments admin XSS. Pantheon says it is "actively monitoring that rule."

The same note is clear on the next step: "However, customers need to update their sites as soon as possible."

The virtual patch covers one of the seven fixes. The comment feed leak, the Imgur embed XSS and the four others are not mentioned as covered. A rule at the network edge is a stopgap. The fix lives in the code.

Why some live sites are still on 7.1.2

WordPress applies minor core releases on its own by default. The WordPress.org guide to automatic background updates says: "By default, every site has automatic updates enabled for minor core releases and translation files." For most sites, the default value of WP_AUTO_UPDATE_CORE is minor.

Several common setups turn that off:

• WP_AUTO_UPDATE_CORE set to false, or AUTOMATIC_UPDATER_DISABLED set to true, in wp-config.php.
• Sites under version control. The same guide describes a filter that turns updates back on when a .git or .svn folder is found. That tells you the default is to skip them.
• Managed hosts with their own update path. Pantheon’s must-use plugin alerts admins to core updates “but disables automatic updates (so those updates can be applied via the upstream).”

On Pantheon, the core updates guide has you apply the update on Dev from the Code tab, then deploy to Test and Live. It also warns: "Do not update core using the WordPress Dashboard, Drush, or WP-CLI; you will overwrite your core."

That three-step path is where updates stall. A typical case: someone applies the update on Dev on October 7. Testing waits for a client. The deploy to Live never happens. The dashboard for Dev shows 7.1.3, and the live site still runs 7.1.2.

Older branches got the same fixes

The announcement says fixes are being backported "to all branches eligible to receive security fixes (currently through 4.7)." It also repeats that "only the most recent version of WordPress is actively supported."

The WordPress release archive lists a release dated October 6, 2026 on every branch from 7.0 back to 6.0. A few of them:

Patchstack’s article, written on release day, said backports reached "at least 6.6," and that branches 4.7 to 6.5 were "yet to be patched" at that time. The archive now lists October 6 releases for 6.0 through 6.5. We did not confirm the 4.7 to 5.9 branches.

A site held on an older branch on purpose should move to that branch’s newest release. Patchstack notes the pending-comment XSS affects 7.1.0 to 7.1.2, so the older branches may not carry every one of the seven issues.

A WordPress 7.1.3 checklist for agencies

Use this on every client site, starting with sites that have open comments.

1. Check the live version. Run wp core version on the live server, or on Pantheon run WP-CLI through Terminus against the live environment. In the admin, Dashboard, then Updates, shows the running version. Do not trust the Dev dashboard or the repository.
2. Find stalled deploys. On Pantheon and similar hosts, list sites where Dev shows WordPress 7.1.3 and Live does not. Deploy them.
3. Check auto-update settings. Search wp-config.php for WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED. If either blocks minor updates, someone has to own every security release by hand.
4. Ask managed hosts. If a host runs core updates for you, ask when WordPress 7.1.3 reached each site’s live environment. Then confirm it yourself.
5. Clear caches. Patchstack says 7.1.3 “does not remove any existing, cached oEmbed content.” A bad Imgur embed can keep rendering until the cache is cleared.
6. Review roles. Patchstack says three fixes need a Contributor or Author account. Remove accounts that no longer need access.

What to check in comments

The comments XSS waits in the pending queue for a moderator. On any site not yet on WordPress 7.1.3, tell moderators not to click links inside pending comments. Approve or delete from the list view instead.

After the update, look through pending comments for odd links or markup, and delete what you do not recognize. If a moderator clicked something before the update, review recent changes made under that account.

For the feed leak, think about which private or unpublished posts had comments. Member-only pages, draft announcements and staff review pages are the likely places. If those comments held anything sensitive, treat it as possibly seen.

How this fits with recent WordPress security releases

This is the third WordPress core security release we have covered in three months. In August, WordPress 7.0.3 fixed a pre-auth login flaw. In September, WordPress 7.1.1 patched Click2Shell. WordPress 7.1.2 followed on September 22 with its own critical fix.

The pattern for agencies is the same each time. The patch ships fast. The gap is between "update available" and "live site updated."

Plugins carry their own risk. Our Bricksforge vulnerability post covers one exploited this month. If you are planning ahead, our WordPress 7.2 beta test checklist covers the next major release. For host choice, see how to choose a managed WordPress host.

Frequently Asked Questions