Every vulnerability disclosure program runs on the same quiet assumption: a report that looks credible probably is. Generative AI broke that assumption sometime this year, and Apple has spent the past few weeks living with the consequences. According to reporting from AppleInsider and HotHardware, Apple's security team has been buried under waves of AI-generated submissions describing vulnerabilities that read convincingly and don't actually work - what one report bluntly called reports that "seemed real, but didn't really work because AI made them up."
Fifty bugs in three weeks, and a $200,000 one nearly lost in the queue
The irony is that the same technology causing the noise also produced one of the more serious macOS findings this year. Bynario ran GPT-5.5 through its own Atlas research platform against macOS for three weeks and surfaced more than 50 candidate vulnerabilities, most of them the usual mix of near-misses and dead ends any fuzzing campaign throws off. One wasn't a near-miss: a privilege-escalation flaw in Screen Sharing that researchers estimated could fetch $100,000 to $200,000 on the exploit black market, serious enough to hand an attacker full control of a Mac. Apple assigned it CVE-2026-43760.
Bynario tried to submit it through the normal channel and hit a wall - not a rejection on the merits, but a hard submission cap Apple had put in place days earlier for an unrelated reason. Apple had to reach back out and pull the report in for manual review once someone noticed what had actually landed in the queue. That near-miss is the whole story in miniature: a filter built to stop machine-written noise came within a support ticket of also stopping a machine-assisted finding that was real.
Why Apple built the cap in the first place
Apple's bug bounty program tops out at more than $5 million for the most severe exploit chains, which is exactly the kind of number that attracts volume over quality once an AI model can generate a plausible-sounding report in seconds. Apple's response, confirmed to AppleInsider, was to limit how many open reports any individual researcher can carry at once and add a 30-day cooling-off period between submission batches, with higher limits available to researchers who ask for them. The company's own statement was matter-of-fact about why: "With the growing volume of AI-generated security submissions across the industry, we recently adjusted the number of new reports a researcher can open at once." Apple also said it now wants concrete proof - working exploit artifacts, not speculative writeups - before a report gets serious triage time.
That's a reasonable policy on its own terms. It's also a policy that, by design, treats every high-volume AI-assisted researcher the same way, whether their output is slop or Bynario's. A cap tuned to stop noise doesn't know the difference between a hundred hallucinated reports and fifty real candidate findings with one genuine six-figure bug hiding in position 43. Apple caught this one because someone flagged it. The interesting question is what happens to the version of this story where nobody does.
The same pattern, pointed at your own inbox
This isn't only an Apple problem. Any organisation running a bug bounty, a vulnerability disclosure program, or even just a shared inbox for external security reports is looking at the same volume curve Apple just hit, on whatever timeline its own visibility makes it a target. We've written before about what happens when AI coding agents start tripping the same detection rules built to catch human attackers - this is the mirror image, AI-assisted researchers tripping the triage systems built to catch human report volume. Rate limits and cooling-off periods solve the resourcing problem. They don't solve the harder one, which is that the review process still has to be good enough to tell a real finding from a convincing fake before either gets stale.
- If your organisation runs any external vulnerability reporting channel, assume the volume of AI-generated submissions is rising whether or not you've noticed it yet, and check whether your triage capacity was sized for last year's volume.
- Don't let a volume-control measure - a rate limit, a submission cap, an auto-triage filter - become the only thing standing between a genuine finding and the person who could fix it. Build a manual escalation path that doesn't depend on someone happening to notice.
- Ask any AI-assisted research vendor or bounty participant you work with how they distinguish a validated finding from a plausible one before it reaches your queue - the gap between the two is exactly where Bynario's flaw nearly got lost.
- If you're running your own AI-assisted vulnerability research internally, budget time for validating your own tool's output before it reaches a submission stage, rather than assuming volume is a proxy for value.
The uncomfortable part of this story isn't that AI is generating bad security reports - that was always going to happen once the barrier to writing a plausible-looking one dropped to nearly zero. It's that the fix for AI noise and the source of a genuine AI-assisted finding turned out to be indistinguishable at the point where it mattered, and only got sorted out because someone at Apple looked twice. If you want help sizing your own vulnerability intake process for a world where report volume no longer tells you anything about report quality, email sales@halfteck.com.