WordPress Got 773 Security Reports in One Month. Nobody Can Read That Many.

I still maintain WordPress sites for four clients. Not because I love it. Because those sites work, the clients are happy, and ripping out something that works to prove a point is a bad way to run an agency.

So when I read that the WordPress security team got 773 vulnerability reports in August, my first thought wasn't "WordPress is doomed." It was: who reads those?

The answer is a small group of mostly volunteers. And the number they used to get was 20 to 30 a month. For about a decade.

That gap is the whole story of WordPress core security right now, and it isn't the story the headline suggests.

773 Reports in One Month. The Ten-Year Baseline Was 20.

Here are the actual numbers, from The Repository's writeup: July was already a record at around 450 reports. August closed at 773. The historical baseline, going back roughly ten years, was 20 to 30 a month.

That is not a trend line. That is a wall.

WordPress security team member John Blackbourn wrote that "unmanageable numbers of low severity reports" forced the scope change, and that the ramp started in January and February, driven mainly by GPT 5.3 and Claude Opus 4.6. His words, not mine: "We're well into an entirely new era of AI-assisted security research."

I want to be careful here, because the easy story is "AI slop is flooding WordPress and the maintainers are drowning." That is half right, and the half that's wrong matters.

Nobody at WordPress published a slop percentage. What they published is that the reports are low severity, not that they're fake. Those are different problems. A pile of 700 real-but-trivial findings is exhausting in a way that a pile of 700 hallucinations isn't, because you can't dismiss any of them without reading them first. That's the actual bottleneck: triage capacity, not garbage detection.

curl Hit This Wall First, and We Have Its Numbers

WordPress didn't publish a validity rate. curl did, and curl's experience is the closest thing we have to a control group.

Daniel Stenberg reported that roughly 20% of curl's incoming reports were AI-generated, and that in one year only about 5% of reported vulnerabilities turned out to be real. His favourite example: a detailed HTTP/3 "stream dependency cycle exploit" complete with GDB sessions and register dumps, referencing a function that does not exist anywhere in curl.

On February 1, 2026, curl shut down its HackerOne bug bounty entirely. One month later, in March, it came back. Read that sequence again, because it's the most honest thing in this whole story. The maintainers hit a wall, took the drastic option, and then found that the drastic option was worse than the wall.

That's the position WordPress is in now, minus the shutdown. Same pressure, bigger surface, more volunteers, and roughly 40% of the web downstream of the decision.

What the WordPress Core Security Scope Change Actually Says

The scope change is two sentences long and it is not "we're rejecting AI reports."

From the updated disclosure guidelines: for any in-scope asset excluding WordPress Core and Gutenberg, issues requiring a role that can only be granted by an administrator will generally no longer be eligible unless they demonstrate a high-severity escalation. And separately, one authenticated role being able to perform an action normally available to another authenticated role is no longer enough on its own, unless it leads to a high impact escalation.

Translated: if you need a Contributor account that an admin has to hand you before your exploit works, that mostly isn't a bounty case any more. Core and Gutenberg keep the old rules for now.

That is a triage filter, not a security retreat. It cuts the class of report that costs a volunteer forty minutes to reproduce and ends with "so an account you deliberately created can do a slightly wrong thing." I've filed things in that category myself, years ago, and I would not want to be the person reading 773 of them.

Alongside it, WordPress launched a Core Security Initiative in August with three stated pillars: a better release process with improved testing, clearing the report backlog by adding people, and using AI-assisted scanning to find vulnerabilities proactively. The last one is the part that made me laugh a little. The volume problem is AI-assisted research, and the answer includes more AI-assisted research, just pointed inward. It might genuinely work. It's also the only lever they have that scales without hiring.

The Number That Should Worry You Isn't 773

Here's what actually matters for the site you own, and it has almost nothing to do with the bug bounty queue.

Patchstack's 2026 report counted 11,334 new WordPress vulnerabilities in 2025, up 42% year on year. Of the new vulnerabilities, 91% were in plugins and 9% in themes. Six were in WordPress core, all low priority.

Six. In core. Out of 11,334.

WordPress core security is, by these numbers, in decent shape. The building is fine. It's the extensions bolted to it that leak, and there are 60,000 of those in the official directory with no security team behind most of them.

Two more numbers from the same report that I think about more than the 773:

• 46% of vulnerabilities weren't patched in time for disclosure. Nearly half went public while the plugin was still broken.
• Among heavily exploited vulnerabilities, 20% were exploited within six hours of disclosure, 45% within 24 hours, 70% within a week. The weighted median time to first exploitation was five hours.

Five hours. That's your patch window, and it starts while you're asleep. I've written before about how attackers are now finding bugs faster than teams can patch them, and this is the same story from the maintainer's side of the desk. Same acceleration, one group has bounty incentives and infinite compute, the other has volunteers and a Tuesday.

What I Actually Do for the WordPress Sites I Still Run

Nothing on this list is clever. That's the point.

Auto-updates are on for core, always, including minor releases. When a client asked me to disable them after a plugin conflict broke a layout, I said no and offered to fix the plugin instead. That took two hours and saved an argument I've had before.

Plugin count is the real lever. One client came to me with 34 active plugins. We're at 11. Nine of the removed ones were doing something a dozen lines of theme code could do, four were abandoned, and two were duplicates of each other because two different agencies had installed their preferred version. Every plugin you delete is a vulnerability you will never have to patch at 3am.

I check maintenance status, not star ratings. Last commit date, open issue count, whether the author replies. A five-star plugin with 400,000 installs and no commit in 18 months is worse than a two-star plugin from someone who ships every month.

And I stopped believing that a security plugin makes a site secure. I wrote a whole piece on which WordPress security plugins are actually worth installing, and the honest summary is that they buy you monitoring and a firewall, not immunity. The stuff that actually moves the needle is boring: fewer plugins, real updates, least-privilege user roles, offsite backups you have actually restored from once. That's most of my website security hardening checklist and none of it needs a subscription.

For new client projects I usually don't start with WordPress at all any more, and I've written honestly about how I choose between WordPress, Next.js and Astro. But "I'd build it differently today" is not a reason to tell an existing client their working site is a liability. It usually isn't.

The Part I Don't Have an Answer For

The 773 number isn't going down. Whatever WordPress does with scope, next year's frontier model will be better at reading PHP than this year's, and the cost of pointing it at a codebase will keep falling toward zero.

So the queue grows, and the only things that scale with WordPress core security are automation and money. WordPress has neither in the quantity this needs. It has a security team of volunteers and a foundation, sitting under a meaningful chunk of the web.

I don't know how that ends. The optimistic version is that AI-assisted scanning on the defensive side catches up, the backlog clears, and in two years this reads like a growing pain. The pessimistic version is that triage capacity becomes the permanent bottleneck in open source security, and the projects that survive it are the ones with a company paying for humans to read reports.

curl quit, then came back a month later. I read that as a maintainer discovering there's no exit, only a queue. I'd rather be wrong about that.

If you're running WordPress and this made you want to actually look at your plugin list instead of just feeling vaguely uneasy, that's the correct reaction. I can't promise you a site that never gets a vulnerability, because that site doesn't exist. What I can offer is a look at what's actually installed, what's abandoned, and what can go. Let's talk if that sounds useful.