I’m not a security researcher. I run a WordPress hosting company. I patch sites, clean up malware, and keep thousands of WordPress sites running smoothly. So when I started pointing AI at the WordPress plugins and finding real vulnerabilities, the first thing I had to get over was the feeling that this was somebody else’s job.
It is not somebody else’s job anymore. Anyone can scan for these now. Not just Wordfence. Not just Patchstack. One person with a Claude subscription and a local WordPress install can audit a large portion of the entire WordPress repository and find bugs that nobody has reported yet.
Getting AI to produce something worth submitting took some trial and error. Huge thanks for Patchstack and Wordfence for not outright banning me for making a bunch of mistakes. Here is the workflow I landed on.
The whole pipeline is four steps.
Each step is a slash command I wrote for Claude Code. The flow is always the same.
/wp-registry-scan against a plugin or theme. Claude fans out parallel sub-agents that read every PHP file looking for injection, missing capability checks, broken access control, and the rest. Out comes a list of findings./proof-of-concept. This spins up a fresh WordPress site locally, installs the exact version, seeds the scenario, and tries to actually fire the exploit. If nothing fires, the finding dies here.Treat every AI finding as a claim, not a fact.
Most of rejections are boiled down to this one fact. AI is very good at reading code and saying “this looks exploitable.” It is much worse at knowing whether the exploit actually works once WordPress’s own defenses are in the way. A finding from an audit is not a vulnerability. It is a claim that needs to be verified.
The fix is almost stupidly simple. Force the AI to stop reading and start running. Have Claude spin up a real WordPress site, install the plugin, and try the attack for real. The false positive rate drops off a cliff the moment you make Claude prove its own claims instead of asserting them from an audit.
My recent example of why this matters happened inside a proof-of-concept for a plugin called Gutenverse. The audit’s headline finding was an image block that echoed an SVG value with no sanitizing. It looked like the obvious bug. So Claude tried to fire it, and WordPress’s wp_kses filter stripped the whole thing. False positive. Then Claude almost made a second mistake.
wp_kses strips tags, so it dies. The Fun Fact finding is an attribute breakout with no tag at all. wp_kses only processes tags, so a tagless value can survive it. I refuted the first one empirically. I am about to refuse the second one on a guess. Let me actually test it before I throw it away.Read that again. The AI almost discarded a genuine vulnerability because it pattern matched it to a false positive. The only thing that saved the finding was the rule that says you have to actually run the exploit. No amount of careful source reading would have caught it. You have to make it real.
Most real bugs are not worth any money. Report them anyway. They are still very real and need patched.
The second thing I had to understand is the gap between “this is a real vulnerability” and “this is eligible for a bounty.” They are not the same set. Plenty of findings deserve to be reported and patched. Very few clear the bar a bounty platform sets, because only the highest impact bugs qualify. Unauthenticated SQL injection, account takeover, that tier. A stored cross-site scripting bug that needs a Contributor account to trigger is a real bug that no major platform will pay for.
My own scorecard makes the point better than I can. Here is what my Wordfence researcher dashboard actually looks like.
That Gutenverse bug from earlier? I proved it end to end, recorded the admin account getting created on camera, and submitted it. Wordfence rejected it as out of scope, because a Contributor-level stored XSS sits in a genuine gap that neither big platform covers. The bug is real. It still needs a patch. It is just not a bounty. So it goes to the vendor directly, which is exactly what step four of the pipeline is for.
Patchstack tells the other half of the story. The same pipeline pointed at their platform had a solid month in May. Ten reports validated. Seven more were valid but came in second, marked duplicate because someone filed the same bug first. Five were rejected. That spread is normal, and the validated ten are the ones that count.
Those ten were not low-severity noise. They ranged from 6.5 up to a pair of criticals at 9.8 and 9.9 on the CVSS scale. Most are still being patched and processed, so they are not public yet. The ones that have gone live are on my Patchstack researcher page, and the month landed me 8th on the May leaderboard.
When something does land, it becomes a public CVE. A few that made it all the way through Patchstack to publication: a 9.3 SQL injection in JetSmartFilters, a privilege escalation in Abandoned Cart Pro for WooCommerce, broken access control in WooCommerce Anti-Fraud, an IDOR in Simple Shopping Cart. Those are the exceptions, not the rule. The value is not the bounty. The value is the coverage.
For context my total May Patchstack payout was around $550. However with bug bounty guidelines getting even more tighter that same work would have yielded $0 for June. It’s now easier to find and report real vulnerabilities. This puts extra workload on all bug bounties causing them to readjust what’s a valid submission.
Two rules that save an enormous number of tokens.
Once the pipeline worked, the only thing left was making it cheap enough to run at scale. Two rules do most of that work.
That second rule is the whole reason this scales. The WordPress ecosystem has a lot of websites but a much smaller number of unique plugin builds. Audit the build, not the install, and a personal-scale operation can cover a surprising fraction of everything.
One person, roughly a thousand plugins a week.
I went back through my own audit logs to see how much this actually covers. In the most recent seven day stretch I audited 918 unique plugin and theme builds. My busiest single day was 396. A typical coverage run chews through 100 plugins in one sitting, with Claude running ten audits in parallel.
The limit was never speed. It is tokens. Every audit spends a chunk of the model’s budget, so what I can cover in a week is whatever fits inside my plan. My plan is the $200 a month Claude Max subscription, and I run all of my other work on that same plan. Even sharing it that way, roughly a thousand plugins a week fits inside the budget. My rough estimate turned out to be almost exactly right.
Surprising the top 5,000 plugins does not turn over as fast as it looks. In that same seven day window, only 612 of those 5,000 plugins pushed an update. Over a full month it was 1,680. A new release is the only thing that creates a fresh build to audit, so this is the real inflow I have to keep pace with.
| Window | Plugins | % of top 5,000 | Installs touched |
|---|---|---|---|
| Last 24 hours | 112 | 2.2% | ~33.7M |
| Last 7 days | 612 | 12.2% | ~81.4M |
| Last 14 days | 984 | 19.7% | ~117.3M |
| Last 30 days | 1,680 | 33.6% | ~184.5M |
I audit close to a thousand builds a week. The top 5,000 ships around six hundred updates in that same week. The inflow is smaller than what one person can process. An individual can keep pace with the popular half of the repository. Not sweep it once and fall behind, but stay current with it, week after week.
All of that feeds a public scoreboard at wpregistry.io/coverage, which tracks the 5,000 most-installed plugins on wordpress.org. Those 5,000 plugins carry around 327 million active installs between them. Here is where the coverage stands today.
The raw count is 2,050 out of 5,000, which sounds like less than half. But coverage is not evenly spread, and that is the interesting part. Break it down by how popular each plugin is and the picture flips.
Every single plugin above 500,000 installs has been audited at its current version. By one person. The popular head of the repository, the plugins running on tens of millions of sites, is fully covered. The gap is the long tail, the plugins with a few thousand installs each, and I am working down into little by little.
That is the whole point. You do not need to be a security company to do this. You do not even need to be a security researcher. You need a clear pipeline, the discipline to prove every finding before you trust it, and the patience to scan everything in the repository one build at a time.