WordPress 7.1.3 shipped on October 6, 2026
WordPress 7.1.3 landed on October 6, 2026, and it is a security and maintenance release: seven security fixes, four bug fixes. The official announcement (opens in new tab) is a short post, and it carries the one line that actually matters for anyone with a site online. Because this is a security release, update immediately.
That is not the usual boilerplate. On a maintenance release I will happily let a site sit for a week while I check that a page builder still renders its grids. On a security release I do not, and this batch is a good example of why. Two of the seven fixes sit in the comments system, which is the one WordPress component that almost every site leaves switched on by default and that accepts input from people who have never logged in.
Three groups get hit hardest here.
- Multi-author sites. Three of the seven issues are permissions or privilege problems, including one that lets an Author account sticky posts it should not be able to sticky. If you run a magazine, a community blog, or anything where you hand out Author or Contributor roles to people you have never met in person, this release is aimed at you.
- Any site with comments open. The stored XSS on the Comments administration page triggers from a pending comment, meaning a comment sitting in your moderation queue is already enough. You do not have to have published it.
- Anyone who turned off automatic background updates two years ago to stop a plugin conflict and then forgot to turn them back on. I have done this on a client staging server myself, and found it fourteen months later.
It is worth looking at who reported these, because the mix tells you what kind of bugs they are. Three came from Anthropic, one from Trail of Bits, one from Patchstack, and two from inside the WordPress security team and the wider researcher community. These are not cosmetic issues in admin CSS or a misaligned toolbar in the block editor. They are memory-safe code review findings and access-control gaps from people who read WordPress core for a living.
If your site supports automatic background updates, there is a decent chance the work is already done. If not, the rest of this post is the order I would do things in, and which two bugs I would fix first if I only had twenty minutes before a client call.
Background: how WordPress 7.1.3 sits in the release line
WordPress does not maintain parallel security branches the way a Linux distribution does. Only the most recent release is actively supported, and anything older receives fixes only where the security team decides a backport is warranted. Everything else is left alone.
The current floor is 4.7. Sites on 4.6 and below are not getting these seven fixes, and that is no longer a patching problem. It is a migration conversation, and it should already be on someone’s list. If your client sites sit on 4.9, 5.3, or 5.8, they are still eligible, which is good news and also a reason to pay closer attention than usual: the patch will arrive as a point release on a branch you probably stopped monitoring. I have had a client’s site quietly move from 5.6.x to 5.6.y overnight because of a backport, and the only reason I caught it was a “What’s new” notice appearing in the admin the next morning. The site was fine. My change log was not.
Backports ship as they become ready rather than all at once, and that delay is deliberate as far as I can tell. Each branch has drifted far enough from trunk that a fix written against 7.1.3 has to be reworked and retested against code that has not seen a functional change in years. Shipping a backport for 4.7 that breaks a legacy theme template is, for that particular site, a worse outcome than the vulnerability it closes. So the older branches wait their turn.
The release itself was led by Jake Spurlock, with a contributor list that runs to roughly three dozen names across a lot of time zones and no shared working hours. Nobody sat in a room and agreed on a freeze date. If you have ever tried to land a three-line config change with a team of four in one office, the fact that this ships at all is a little remarkable. I will not reproduce the names here, because the announcement post (opens in new tab) does that already, and clicking through is a decent reminder of how much unpaid review work sits behind a version number.
What matters for you is simpler than any of this. 7.1.3 is the supported target, the old branches are being serviced in the background, and neither of those facts removes the need to check your own footer.
What’s happening now: the 7 fixes in WordPress 7.1.3
Seven security fixes is a lot for a point release, and the mix of reporters is a decent signal that none of these are cosmetic CSS bugs nobody would weaponise. Three came from Anthropic, one from Trail of Bits, one from Patchstack. That is a research-heavy batch.
The one I would patch for first is unauthenticated disclosure of comments on private and unpublished posts, reported by Ananda Dhakal at Patchstack. No login. No account. No plugin. If a post is a draft or set to private and someone has commented on it, the comment content can leak. Think about what sits in drafts: a product launch, a client announcement, a post-mortem you have not finished. The comments underneath it are sometimes the more interesting half. If your site runs open comments and you keep drafts lying around, this is your reason to update today.
Next, stored XSS on the Comments administration page, exploitable via pending comments, reported by Thomas Chauchefoin at Trail of Bits. The part worth understanding is that the malicious comment does not need to be approved. It just needs to sit in the moderation queue. You open /wp-admin/edit-comments.php to clear out spam, the payload fires in your browser, and your admin session is the target. Anyone who can submit a comment is a potential attacker here, which on most sites means anyone at all.
From Anthropic, three separate reports. A DoS in WP_Http::make_absolute_url() is a resource exhaustion issue, not a data leak, but it can still knock a site over. A second-order SQL injection in the WXR export requires export privileges, so it matters most if you have handed Author or Editor accounts to people you do not fully control. The third, a weakness letting Author role users sticky posts, is a permissions bug. Annoying, not a breach.
The remaining two: XSS in Imgur embeds, reported by Zhengyu Liu, Jingcheng Yang and Gavin Zhong, which is exactly the kind of thing that hides in a post from four years ago that you have forgotten exists. And forgeable parameters passed to the {status}_{type} hook that can cause action name collisions, reported by Alex Concha of the WordPress security team.
My shortlist, if you only have time for one: the comment disclosure, because it needs nothing from the attacker except a browser.
What it means in practice
That shortlist shifts depending on what you actually run, so here is how it shakes out.
If your site is small and personal, this still applies to you. The comment disclosure bug does not need an account, a plugin, or a particular theme. It needs someone to guess a post ID and request the comments for it. Site size is not a shield. If you have comments closed and you have never embedded an Imgur image in your life, your exposure drops, but the admin-side fixes still matter to anyone who can log in, and that includes you.
The two to patch first. The unauthenticated comment disclosure and the stored XSS in the comments admin page, because both live in a component most WordPress sites leave switched on. Picture a site with 400 comments sitting in the moderation queue. You log in on a Monday morning to clear spam, the payload in one pending comment runs in your browser, and it is doing whatever it was written to do with your session while you are still clicking Trash. The WXR export SQL injection needs export privileges, so it drops down the list unless you hand export access to authors or editors. The Author-role sticky post issue is a permissions bug rather than a data leak. Annoying, not urgent.
Your site may have already updated itself. If it supports automatic background updates, the process started on its own and it will flip to 7.1.3 without you touching anything. If updates are disabled, or you are on a host that pins versions, do it manually: Dashboard > Updates > Update Now, or wp core update from the command line. Then confirm the footer of wp-admin reads 7.1.3, or run wp core version. I have had clients insist they were on the latest release and turn out to be three point versions back because a plugin had quietly blocked core updates.
Two places people forget to look: multisite networks, where the individual sites only move when the network admin runs the update, and staging environments still pointed at a copy of production data. A staging site with an old admin login you stopped using is still a door, and nobody remembers it exists until something shows up in the logs.
What to expect next after WordPress 7.1.3
The backports are not finished. The release notes say the security fixes are being ported to every branch still eligible, currently everything back to 4.7, and that they will ship as they become ready rather than in one drop. That means a site sitting on 5.9 or 6.1 can get its own small point release in the next few weeks without an announcement you would ever notice. If you maintain sites across several old branches, put a calendar reminder to check the releases feed weekly rather than waiting for a dashboard badge.
I look after a handful of client installs that are still on older branches because a page builder broke on a newer version and nobody wanted to pay for the migration. Those are exactly the sites where a backport arrives quietly, applies over SSH at 3am from a cron job, and leaves a fatal error nobody sees until a customer emails. Test the backport on staging before you let it touch production, even though it is a security fix. A site that is down is not more secure.
Plugin and theme authors will spend the days after this re-running their suites against the patched code. That is where breakage usually comes from, not core. Anything that filters comment query arguments, builds hook names from a status and a type, or touches WP_Http is worth watching. Pay particular attention to {status}_{type} usage, since that fix changes how action names are formed and a plugin that depended on the old collision behaviour may stop firing.
My expectation, and this is only a guess, is that the comment system stays the soft spot for a while. Two of the seven fixes here touch comments directly, and the admin moderation screen is the one page an editor opens every single day. I would not be surprised to see more of the same in the next point release.
What to do this week: run wp core version against every site you own or manage, list anything below 7.1.3, and sort the list by who pays you for it. Then either push the update or write down why that site is still on an old branch, so the next time it comes up you are not starting the conversation from zero.