The Bots Found 450 Ways Into WordPress Last Month
Bug bounty reports on WordPress core sat at 20 to 30 a month for a decade. Last month it hit 450. Here’s what changed, and what it actually means if you own a site.
WordPress just shipped version 7.0.3, patching a dozen security holes. Nothing unusual about that on its own — core ships security fixes regularly. What’s unusual is who found them. Alongside the usual independent researchers, the credit list includes Anthropic and a handful of AI penetration-testing firms.
That’s not a coincidence. According to the WordPress Security Team, reports to the project’s bug bounty program held steady in the 20-to-30-a-month range for roughly a decade. Then, starting this January and February, that number started climbing. By July it had hit 450 — a jump the team attributes mainly to AI-assisted security research picking up speed.
“We’re well into an entirely new era of AI-assisted security research.”
— John Blackbourn, WordPress Security Team
Here’s the part that matters for anyone running a WordPress site, not just the people who build them. The tools that find vulnerabilities faster don’t stay on one side of the fence. The same automation that let a researcher find a critical WordPress flaw for about $25 in AI token costs a few weeks back is available to anyone, including the people who aren’t reporting what they find. The cost of discovering a hole in your site’s defenses just dropped, and it dropped for everybody.
It’s not theoretical. This week Poland’s government cybersecurity office issued a formal advisory over a set of WordPress core flaws patched back in July — two vulnerabilities that, chained together, could let an attacker inject malicious database commands and ultimately run code on the server. They classified it as a threat to public infrastructure and told affected organizations to update immediately.
There’s also friction working against site owners right now. WordPress.org’s “Protect the Shire” policy, introduced this summer to slow down supply-chain attacks, currently holds every plugin and theme update — security fixes included — for about six hours before it reaches your dashboard. Patchstack’s own research puts the typical time-to-exploitation for a disclosed vulnerability at around five hours. That’s not a lot of daylight between “the fix exists” and “someone’s already using the old bug against you.”
This is exactly why we don’t leave client sites on the default schedule. Every site we maintain gets a web application firewall, active plugin vulnerability monitoring, and patches applied on our own timeline — not whenever the platform gets around to releasing them. The tools finding these holes have gotten faster. The response has to keep pace.
“The bots don’t wait for your maintenance schedule. Neither do we.”
