WordPress 7.1.3 shipped on October 6, 2026. Seven security fixes, four bug fixes, led by Jake Spurlock.
That’s the third security release since September 18. 7.1.1, then 7.1.2, now this. Nineteen days, three emergency updates — and if your reaction to that is mild fatigue rather than alarm, that’s worth paying attention to, because fatigue is exactly how sites end up running a version that was patched a month ago.
What’s actually in it
Seven vulnerabilities, none of them an unauthenticated remote code execution like 7.1.2 carried. This is a less dramatic release. It is not an optional one.
Stored XSS on the Comments administration page, reported by Thomas Chauchefoin at Trail of Bits. This is the one that matters most in practice. The payload goes in through the comment form — no account, no authentication, nothing — and sits in the moderation queue until an administrator opens the Comments screen. At that point it executes with that administrator’s session. If your site accepts comments and someone reviews them, you are the target.
Unauthenticated disclosure of comments on private and unpublished posts, reported by Ananda Dhakal at Patchstack. Comments attached to drafts and private posts could be read without logging in. For an editorial team or an agency working on unreleased content, that is a confidentiality problem rather than a technical one.
A DoS in WP_Http::make_absolute_url(), a second-order SQL injection in the WXR export, and an Author-role user being able to make posts sticky — all three reported by Anthropic. More on that below.
XSS via Imgur embeds, reported by Zhengyu Liu, Jingcheng Yang and Gavin Zhong. oEmbed handling again, which has a history.
Forgeable parameters passed to the {status}_{type} hook, allowing action name collision, reported by Alex Concha of the WordPress security team. The most abstract item on the list and the hardest to exploit, but it’s a core hook that plugins attach to constantly.
The part nobody is talking about
Three of the seven reports came from Anthropic.
Not a security vendor. Not a bug bounty researcher. An AI lab, running automated analysis across the WordPress codebase and finding a SQL injection, a denial-of-service vector and a privilege issue in a single pass.
This is the direction things are going, and it cuts in a specific way: the same tooling that finds bugs for the security team finds them for everyone else too. The window between a vulnerability existing in public code and someone noticing it is getting shorter. The window between a patch shipping and a site being attacked is getting shorter with it.
Which makes the interval between patch released and patch installed on your site the only variable you actually control.
Three releases in nineteen days is the real story
Here is what that cadence does to a site that isn’t actively maintained.
Auto-updates handle most of it, quietly, which is good — until a plugin breaks against the new core version and the site goes down overnight with nobody watching. We wrote about exactly that happening with Elementor two weeks ago. Or auto-updates are switched off, usually after one bad experience, and then nothing arrives at all. The site runs 7.1.0 for six months while three separate security advisories pile up against it.
Both failure modes look identical from the outside: nothing happened. One of them is fine. One of them isn’t. You can’t tell which without looking.
And there’s a detail in every one of these release posts that gets skimmed past: only the most recent version of WordPress is actively supported. Backports to older branches do happen, currently down to 4.7, but they ship after the main release, as they become ready. If you’re holding on an older major version because an upgrade is risky, you are not getting these fixes on day one. You’re getting them eventually.
What to do today
Update to 7.1.3. Dashboard → Updates → Update Now. If auto-updates are on, it may already be done — verify rather than assume.
Then check the comment moderation queue before an administrator opens it casually. If the site was running an unpatched version with comments open, the XSS payload could already be sitting there. Clear pending spam, and if anything looks malformed, delete it from the database rather than through the admin screen.
Then confirm the update actually completed. A core update that reports success and a core update that worked are not reliably the same thing. Check the version number under Dashboard → Updates, confirm the site loads on the front end and in wp-admin, and look at your error log for anything new.
Then decide what happens next time. Because there will be a next time, and on current evidence it won’t be long.
The uncomfortable arithmetic
Three security releases in nineteen days means three moments where a site either got patched promptly, got patched late, or broke during the patch. If nobody is responsible for which of those happened, it happened by luck.
That’s the entire argument for maintenance, and it has nothing to do with how good your site is.
Site running an older version and you’re not sure what’s exposed? Get in touch — phone, email or live chat.
Update broke something? WordPress repair covers exactly this.
Want core updates staged, tested and verified before they reach production? Our WordPress Maintenance package is $69/month, fixed — updates tested on staging first, licences monitored, offsite backups, uptime watched. WooCommerce stores are $89/month.
