Hit the ceiling and the next move is paperwork: ask Apple for a bigger quota, or wait out 30 days [2]. The number that ceiling sits at does not appear in the account published by 9to5Mac's Bradley Chambers, an Apple IT admin since 2009 [15][16]. That is the practical problem for a researcher holding something live. You cannot pace disclosures against a limit you can only find by tripping it.
In the one case with a name attached, the volume that tripped it was small. Bynario, a seven-person startup, filed five reports to Apple this year and eight in 2025 before its submissions were blocked, according to a Financial Times report cited by Chambers [5]. That is 13 reports in total [13], roughly 1.9 per employee across the whole period [14]. One of them was patched in November [6]. Apple is reviewing the firm's findings now, including a privilege-escalation exploit chain that could give an attacker full control of a Mac [7]. The column places the block first and the review after the FT wrote it up, and does not say the coverage caused the review [5][7].
Chambers' argument against the cap runs through Coldcard. From late July, attackers drained more than $116 million in bitcoin from thousands of hardware wallet addresses [8], and the root cause was a firmware bug shipped in March 2021 that quietly made the device skip its true hardware random number generator and fall back to a weaker software substitute when generating private keys [9]. He writes that he believes AI tools were likely a factor in the flaw finally being found and exploited at scale [10]. No evidence for that link appears in the piece, so read it as his inference rather than a finding. What holds up without it is the asymmetry he names: attackers get no 30-day cool-off between attempts [12].
For anyone running vulnerability intake, a count cap is the cheapest throttle to build, and the cheapest one is the one that treats every submitter as the same submitter. Two axes are worth drawing before copying it: cost to file, and cost to review. Machine-generated slop is cheap to file and expensive to review. A Bynario-style exploit chain is expensive in both directions. A per-account count cannot separate those, because it never looks at who is filing. A quota weighted by submitter history can, and Apple's quota-increase request is the manual version of that, with the researcher carrying the wait. Chambers' verdict is that the fix for a triage problem is better triage rather than slower submission [11].
Security leads cannot yet say that disclosure to Apple takes longer end to end; the column reports no measured change in fix times [17]. What it does document is one queue closing on one small firm sitting on a full-control Mac exploit chain [5][7]. The number worth knowing about your own intake is how many days your best-known outside reporter needs to get an urgent finding past your throttle, counted from the day they hit it. If the shortest path on record runs through a journalist, escalation has quietly been outsourced.
