Why WordPress, and why bother with bounties
WordPress runs a large share of the web, and almost all of its attack surface lives in third-party plugins rather than the well-audited core. There are tens of thousands of them, written by volunteers of every experience level. That is precisely the sort of large, unfamiliar codebase an LLM reads quickly and tirelessly, which made it the obvious place to see whether the Drupal technique scaled.
The commercial test mattered too. Two programmes actually pay for third-party WordPress plugin vulnerabilities: Wordfence, which runs disclosure itself and pays up to five figures scaled by a plugin’s active-install count, and Patchstack, which runs a monthly leaderboard and zero-day bounties on the same install-scaled basis. The independent open-source routes that used to exist have mostly closed: the Internet Bug Bounty paused open-source submissions, and huntr pivoted to AI/ML challenges. So the question was narrow and answerable: point good tooling at the corpus, disclose responsibly, and see whether the payouts cover the effort.
The scanner: why grep is useless here
The naive approach is to grep every plugin for dangerous sinks - $wpdb->query, echo $_GET, file_get_contents on user input - and read the hits. That produces a mountain of noise, because a raw text match cannot answer the only question that matters for a vulnerability: who can reach this line? A dangerous-looking sink guarded by a capability check or a nonce is not a bug. A boring-looking one reachable by an unauthenticated visitor is.
So the scanner does not grep. It tokenises each plugin with PHP’s own token_get_all() and reconstructs the thing that actually decides exploitability: the join from a registered hook (a REST route, an admin-ajax action, an init callback) to the body of its handler, and from there to the guards that protect it and the sinks it reaches.
hook registration -> handler body -> guards + sinks
add_action('wp_ajax_nopriv_x', 'h') function h() current_user_can()? $wpdb->query()
check_ajax_referer()? fwrite()
Two details did most of the work. Guards are frequently not in the handler at all - a plugin might funnel every request through a single Security::verify_request() helper - so the resolver follows calls a couple of levels deep before deciding a handler is unguarded. And it distinguishes the nopriv variants of AJAX and REST registrations, because those are the ones an unauthenticated attacker can reach, which is where the payable severity lives.
None of this is exotic. It is a small amount of careful static analysis that turns a text search into a reachability question. The AI’s role was in reading the flagged handlers and explaining what each one did, and in drafting the reproductions - not in deciding what counted.
The funnel, honestly
I indexed 4,455 plugins from the 10,000-to-2-million install band, unpacked and scanned about 2,180 of them, and the scanner flagged hundreds of candidates. That number is not a count of bugs. It is a count of leads, and treating it as anything more is the mistake that gets researchers banned from these programmes. Working through them by hand - standing up a real WordPress install and actually reproducing the behaviour - left eight findings that survived. Of those eight, exactly one was cleanly inside the current bounty scope. That one has since been validated by the programme and is working through disclosure, so I will not name it here until it is public.
The scope gate is the whole story
Here is the part that turns a pile of real findings into almost no money. As of June 2026, Patchstack only accepts a report if it meets a specific list of impacts. A cross-site request forgery, for instance, is accepted only if it chains into an accepted write action - SQL injection, file operations with full path and extension control, remote code execution, PHP object injection, an impactful settings change, privilege escalation to contributor or above. A missing authorisation check on a settings or integration endpoint, which is exactly what a scanner like mine is best at finding, is explicitly out of scope unless you can show it reaches something that matters.
There are two more filters stacked on top. Reports below 1,000 installs are out of scope unless the severity is very high, and the payout is scaled hard by install count - roughly a hundredfold across the range, from a few hundred dollars at the bottom to five figures for the largest plugins. And there is an automatic one-week ban for reports built on incorrect AI-generated assumptions or clearly not tested against the real plugin. For scanner-assisted research that clause is not a footnote; it makes hand-verification non-negotiable. A marginal submission is not a free lottery ticket, it costs a week and your standing.
Where the money actually is, and why I missed it
Put the scope gate and the install-scaling together and the strategic error becomes obvious. My corpus was the 10k-to-2M band, and in practice mostly the bottom of it. That is the cheap end of a scale that pays a hundred times more at the top, and the bug class my scanner is tuned to find - missing authorisation on an endpoint - is the class the June rules most often exclude. So the pipeline was efficient at producing exactly the findings the market values least.
The honest split. The tooling did the reading and the reachability analysis at a scale I could never do by hand, and the AI drafted clear explanations and reproductions. But every decision that carried value - is this reachable by the right role, does it chain into an in-scope impact, is it worth a real person’s time to receive - was human judgement, and no amount of scanning substitutes for it. The bottleneck was never finding candidates. It was judging them, and choosing better targets in the first place.
If I ran it again, I would invert the target selection: bias hard toward plugins with hundreds of thousands or millions of installs, and tune the scanner for the classes that pay - privilege escalation, SQL injection, PHP object injection, and file read or write with full path and extension control - rather than the missing-nonce settings change that is now mostly worthless. Fewer, better targets, and a scanner pointed at impact rather than at the easiest-to-find flaw.
What this means if you run a WordPress site
Two things are worth taking from this, and neither is about bounties. First, the economics that make plugin vulnerabilities barely worth reporting for money are the same economics that leave a very long tail of small and mid-size plugins under-reviewed. When you install a plugin you are trusting code that, in many cases, no security reviewer has looked at line by line, and the market gives almost no one a reason to. That is not a reason to panic; it is a reason to keep plugins updated promptly when advisories do land, to remove the ones you are not using, and to be conservative about what you install on a site that takes payments or holds customer data.
Second, the same AI-assisted reading that struggles to pay as a bounty play is genuinely useful pointed at a single site you care about: reading the specific plugins that site depends on, flagging where user input reaches a sink unguarded, and verifying the handful that look real. That is a support task, not a lottery, and it is the kind of attention I bring to the sites I look after. If you would like that on a WordPress or Drupal site that matters, the contact details are below.