Why WordPress Keeps Shipping Security Updates in 2026 (and What to Do)

Last updated 14 October 2026.

If it feels like WordPress has been asking you to update every other week since July, you’re not imagining it. Between 17 July and 6 October 2026, WordPress shipped six security releases with 34 security fixes. For comparison, the release posts list 6 security fixes in all of 2024 and 2 in all of 2025.

The short reason: AI got good at finding bugs. Security researchers, and now AI labs themselves, are pointing new models at WordPress and finding things that sat unnoticed for years. Attackers have the same tools. Here’s what happened, in plain words, and what it means for your site.

The numbers

We went through every release post in the WordPress releases archive back to late 2023 and counted the security fixes each one lists:

That’s not counting the 6.9.3 and 6.9.4 follow-ups in March, which fixed problems with 6.9.2 itself rather than adding new security fixes.

The bug bounty side tells the same story. WordPress’ HackerOne page showed 2,147 reports received in the last 90 days when we checked on 14 October, and $90,000 to $95,000 paid out in bounties over the same window. The security team’s John Blackbourn has said reports ran at roughly 20 to 30 a month for about a decade before this year, according to The Repository. 2,147 in 90 days is around 700 a month.

The last 12 weeks, release by release

Where AI comes in

The official release posts credit the people who reported each bug. Across those 34 fixes, Anthropic is credited on 6 (one in 7.0.3, two in 7.1.1, three in 7.1.3) and OpenAI on 1, together with the security firm Trail of Bits. A firm called pwn.ai is credited on 3 more.

The biggest one, wp2shell in July, is credited to Adam Kues at Searchlight Cyber. The Next Web reported that he found it with an OpenAI model in about 10 hours, and that attacks started within hours of the fix going out.

The WordPress security team says this openly. When it launched the Core Security Initiative on 28 August, it put the jump in reports partly down to advances in frontier AI models. One of the initiative’s three goals is to run AI-assisted scanning itself, so the team finds the bugs before someone else does.

So is WordPress suddenly less secure? We don’t think that’s the right reading. These bugs were already there. What changed is how cheap it became to find them. Every fix shipped is one fewer bug for an attacker to find on their own.

What the 7.1.3 fixes mean, in plain words

Security notes are written for developers. Here’s the latest batch translated:

• Stored XSS on the Comments screen via pending comments. Someone could leave a booby-trapped comment, and when you opened your comments page to moderate it, code would run in your browser while you were logged in as admin.
• DoS in WP_Http::make_absolute_url(). A crafted URL could make that function chew up the server, slowing or stalling the site.
• Second-order SQL injection in WXR export. Bad data stored earlier could be turned into a database attack later, when someone ran Tools › Export.
• Authors could make posts sticky. A permissions slip. Authors shouldn’t be able to pin posts to the top of your blog.
• Comments on private and unpublished posts could be read by logged-out visitors. A privacy leak, no hacking skill needed.
• XSS through Imgur embeds. A crafted embed could run code on the page.
• Forgeable hook parameters. A developer-level issue where one action could be mistaken for another inside WordPress’ event system.

Patchstack’s breakdown of 7.1.3 sorts them by who can trigger them: only two can be reached by a logged-out visitor, and one of those still needs a moderator to click. The rest need a Contributor, Author or admin account. So it’s an “update this week” release, not a “drop everything” one. wp2shell in July was the opposite: no login, no click, full takeover.

Quick glossary

• XSS (cross-site scripting): getting your own JavaScript to run in someone else’s browser on a site they trust.
• SQL injection: sneaking database commands into something the site sends to its database.
• DoS (denial of service): making the site too busy to answer real visitors.
• RCE (remote code execution): running your own code on the server. The worst one.
• Pre-auth / unauthenticated: works without logging in. That’s what makes a bug dangerous at scale.
• Contributor+ / Author+: needs at least that user role, so it mostly matters on sites with several writers.
• Backport: the same fix copied into older WordPress versions.

How many sites are actually up to date?

WordPress.org publishes live version stats. Here’s what they showed on 14 October:

Source: api.wordpress.org/stats/wordpress. Two caveats. These numbers count branches, not exact versions, so a site on 7.1.0 counts the same as one on 7.1.3. And an old branch isn’t automatically unpatched: security fixes are backported all the way to 4.7, so a 6.4 site with minor auto-updates on should still have the fixes. The sites to worry about are the ones where auto-updates are switched off and nobody’s watching.

PHP is the other half. The same PHP stats show 16.3% of WordPress sites still on PHP 7.4, which stopped getting security fixes from the PHP project in November 2022. About 22% are on something older than PHP 8.0. WordPress can patch itself. It can’t patch the PHP your host runs.

What you should do

1. Check your version. Dashboard › Updates. If it isn’t 7.1.3 (or the latest minor of your branch), update now.
2. Make sure minor auto-updates are on. They are by default. Some hosts and some “performance” plugins turn them off. If yours are off and you don’t have someone updating by hand within a day or two, turn them back on.
3. Check your PHP version. Tools › Site Health › Info › Server. If it starts with 7, ask your host to move you to 8.2 or newer. Test on staging first.
4. Look at your user list. Many of this year’s bugs need a Contributor or Author account. Delete accounts nobody uses and don’t hand out roles you don’t need to.
5. Don’t forget plugins. Core gets the headlines, but most WordPress vulnerabilities are in plugins. Remove plugins you’ve stopped using and watch for ones that have gone quiet (how to spot an abandoned plugin).
6. If an update breaks something, roll back the plugin, not the security update. Our plugin conflict guide walks through finding the culprit.

Expect this pace to continue. WordPress 7.2 is due on 8 December, and it brings a new HTML sanitizer built partly with security in mind (our early test of WordPress 7.2). The bugs AI is finding now are the ones that would have been found the slow way over the next decade. Better they turn up in a release note than in your server logs.

How we counted

Security fix counts come from the list of credited reports in each official release post on wordpress.org/news, from WordPress 6.3.2 (October 2023) to 7.1.3 (6 October 2026). Releases that only fixed regressions were not counted. AI-company credits count fixes where Anthropic or OpenAI is named in the credit line. Version and PHP shares come from the public wordpress.org stats API, read on 14 October 2026.

Frequently asked questions

Why are there so many WordPress security updates in 2026?

AI models have made finding bugs much faster and cheaper. WordPress’ bug bounty went from about 20 to 30 reports a month to roughly 700, and the security team is fixing what comes in. The bugs aren’t new, they’re just being found now.

Is it safe to let WordPress update automatically?

For minor security releases, yes, and it’s the default. These releases only contain fixes, and WordPress.org even forced the July 7.0.2 update because of how serious that bug was. Keep a recent backup either way.

My site is on an older version of WordPress. Am I exposed?

Not necessarily. Security fixes are backported to every branch back to 4.7, so an older site with minor auto-updates on still gets them. The real risk is a site with auto-updates switched off, or one running PHP 7.4 or older.