# Apple's Bug Bounty Program Is Choking on AI-Generated Ghost Exploits
When Apple built its Security Research Device Program and expanded bug bounty payouts to seven figures for critical findings, the implicit contract was simple: researchers find real flaws, Apple pays real money, everyone's software gets more secure. That contract is now under serious strain — not from state-sponsored hackers or ransomware gangs, but from a flood of AI-hallucinated vulnerabilities that never existed in the first place.
Apple has imposed hard new submission limits on its bug bounty portal after the system was buried under waves of low-quality, AI-generated reports describing security flaws that don't exist. Researchers using large language models to generate submissions at scale have gamed the volume side of the equation while completely failing the accuracy side. The result: Apple's security team is now spending significant triage cycles on phantom bugs.
## The Signal Is Gone
Bug bounty programs have always had noise. Duplicate reports, out-of-scope submissions, researchers misunderstanding severity ratings — this is baked into the model. But what Apple is dealing with now is categorically different from a confused first-timer submitting a self-XSS with a $50,000 ask.
AI models, when prompted to generate vulnerability reports, are extremely good at producing plausible-sounding outputs. They can mimic the technical language of a real CVE write-up, structure a proof-of-concept walkthrough, and even cite relevant CWE categories — all for a bug that doesn't exist in the version of the software they're describing, or anywhere at all. The reports look credible until someone actually tries to reproduce them.
That reproduction step is precisely what's breaking Apple's triage. Every fake report that gets escalated for hands-on verification is analyst time that could have been spent on a real zero-day. Multiply that across hundreds or thousands of AI-generated submissions and you have a triage backlog that becomes a genuine security liability.
Submission limits are Apple's blunt-force response. They work in the sense that they cap the volume any single account can push through. They don't fix the underlying problem, which is that quality verification at the front door is now the hardest part of running a bug bounty program.
## The Legitimate Researcher Gets Squeezed
Here's the friction that doesn't show up in the headline: when Apple imposes submission limits, those limits apply to everyone. A researcher who's found a genuine, sophisticated memory corruption bug in the kernel extension framework and is documenting three related variants now hits the same cap as the person submitting AI-generated nonsense.
This is how defensive measures in security programs tend to work — the bad actors impose costs on everyone. We saw it with coordinated vulnerability disclosure windows that became too short for complex bug chains to be properly documented. We saw it with reputation systems on HackerOne that punished first-time submitters regardless of finding quality. Now we're seeing it with rate limits that treat a prolific AI spammer and a methodical security researcher as the same class of actor.
The researchers who have historically made bug bounties worth running — the ones who spend weeks reversing a CoreBluetooth implementation or mapping attack surface across a new kernel subsystem — aren't operating at volume. They submit once, carefully, with complete documentation. Throttling submission rates does almost nothing to deter them, but it does add friction and communicates something uncomfortable: your program has become adversarial to deal with.
## This Is Not Unique to Apple
Apple's program is large and high-value enough to attract this kind of abuse first, but the pattern is already spreading. Security researchers who participate across multiple programs have described similar upticks in AI-assisted submissions across HackerOne and Bugcrowd platforms. The economic logic is obvious: if you can generate 200 plausible-looking reports per day with a few well-crafted prompts, even a 1% acceptance rate on programs with modest payouts produces meaningful money with minimal actual security knowledge required.
Program operators are in a difficult position. Automated screening catches some of this — reports for vulnerabilities in deprecated API versions, descriptions that cite nonexistent function names, PoC code that wouldn't compile against the target library. But the better AI-generated reports are getting past basic automated triage. The tell is usually in the reproduction steps: they're coherent, they're wrong, and they're wrong in ways that only become apparent when someone who knows the codebase actually tries to follow them.
Some programs have started requiring researchers to submit working proof-of-concept code with certain report categories. That's a real filter — you can't hallucinate a working exploit the way you can hallucinate a vulnerability description. But it also raises the floor for legitimate researchers working on classes of bugs where a safe PoC is genuinely difficult to construct without risking harm to production systems.
There's no clean answer here. Bug bounty programs are going to spend 2025 and 2026 iterating through increasingly sophisticated intake filtering, and the better-resourced programs will survive it. The smaller ones, run by teams without dedicated triage capacity, may not.
---
## HackWire Analysis
The part of this story that isn't getting enough coverage: the real danger isn't wasted triage hours. It's the missed real bug.
Consider what happens when Apple's security team is processing a backlog of 400 AI-generated reports and, buried somewhere in that queue, is a legitimate critical finding from a researcher who didn't have the name recognition to get a direct channel to Apple's security team. Triage prioritization under volume pressure is imperfect. The legitimate report gets delayed, or miscategorized, or handled by an analyst who's already mentally fatigued from the preceding 50 phantom bugs. That's a real attack surface window.
Bug bounty programs have always operated on a trust model: the researcher trusts the company to act on reports in good faith; the company trusts the researcher to submit findings in good faith. AI-generated slop submissions are a violation of that trust at scale, and the damage is measured in exactly the kind of outcome security programs exist to prevent — a real vulnerability that sits in a backlog instead of getting patched.
What's also interesting is the precedent Apple's submission caps set. This is almost certainly the first of many structural responses we'll see across the industry. The next likely evolution: tiered submission tracks where researchers with verified prior successful disclosures get a higher cap or a faster review queue, while new accounts face stricter limits. That's reputational gatekeeping, and it has its own problems — it advantages insiders and makes it harder for newcomers to break into the field.
The long-term fix is probably mandatory working PoC for higher-severity classes, combined with something like a researcher reputation score that factors in report accuracy, not just report volume. Until that infrastructure exists, programs will be playing whack-a-mole with submission limits, and the people who'll feel it most aren't the ones submitting AI slop.
— HackWire Editorial
---
## Related Coverage