Build1 publisher2 min readPublished
Turso retired its $1,000 bug bounty after LLM reports outran one maintainer's reading speed
The program paid for critical vulnerabilities for about a year and closed because generating a plausible report now costs about a tenth of a cent while reading one still costs ten minutes of the person who knows the code.
The Engineer · Build desk
What happened
- Turso, a SQLite-compatible database written in Rust, retired the bug bounty it had run for about a year paying $1,000 per critical vulnerability, in a post titled "The wonders of AI".
- Reading time was the binding constraint: most of the reports reaching the maintainer's inbox were written by an LLM, and reading them consumed most of his bounty hours.
- One submission claimed to have found a critical flaw that let an attacker execute arbitrary SQL statements, against a SQL database.
- Producing a vulnerability report against a public codebase costs roughly a tenth of a cent, and a human needs about ten minutes with one before concluding it is not real.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint The limit on an open bounty is the maintainer's reading hours, so the queue clears at reading speed whatever the payout is.
- cost About a quarter of a dollar of inference can consume a full week of one maintainer's undivided attention, and the project pays that bill in the time of the person who understands the code.
- decision Teams with an open submission form are choosing between auto-closing everything, which discards the real reports, and triaging until someone quits.
- precedent Effort is going into automating rejection, and nobody automates the fix. Closing the intake is the cheapest remedy a small team can actually apply.
A bounty works because the two sides of it cost roughly the same. Finding a real critical vulnerability is hard and writing it up takes hours, so submission volume throttled itself and the queue stayed near the rate of real findings, which is the rate a small team can triage. A dev.to post on Turso's decision gives that account [10]. Cheap inference broke the assumption in about eighteen months [12].
Queues do not degrade gracefully when arrivals outrun service. The post puts it in operational terms: once the submission rate climbs past the triage rate the queue does not stabilise, and it grows until the maintainer gives up reading or gives up the program [11].
Ten minutes a report is six reports per maintainer hour [9]. Give one maintainer a 40-hour week with nothing to do but triage and that is 240 reports, which cost about 24 cents of inference to produce [18]. The payout for one real critical vulnerability, $1,000, would fund a million generated reports at the same unit price [19].
Those ten minutes have to be spent, and the submissions show why. One report described a buffer overflow whose reproduction steps began with editing Turso's own source, recompiling with a forced volatile write past the end of a vector, and running the modified binary [6]. The vulnerable code paths did not exist and the exploits did not reproduce [7].
The same post extends the pattern to drive-by pull requests on popular GitHub repos, to issue trackers filling with reports filed without reproduction steps, often by a chatbot middle layer that promised a confused user it would "let the developers know", and to review comments arriving thirty at a time on small pull requests [13][14][15]. The post attaches no rates to any of it: no count of the submissions Turso received, no period, and no claim that Turso is the first program retired for this reason [20].
On where the tooling has gone, the post says: "We have automated finding bugs. We have automated submitting bugs. This year we are automating rejecting bugs. Nobody is automating fixing them." [16]
Intake is the part a small team can still change. A bounty that requires a reproducible case against an unmodified release build rejects the recompile-your-own-overflow submission before a human opens it [6]. The report claiming an attacker could execute arbitrary SQL against a SQL database survives that rule, and someone who knows the product has to read it.
What to watch
- Whether Turso or a comparable project publishes an invalid-report rate and puts measured numbers where one post's estimates of a tenth of a cent and ten minutes now sit.
- Whether large bounty platforms add an intake requirement for a reproducible case against an unmodified release build, and what that does to accepted-report volume.
- Whether GitHub adds submission gates for drive-by pull requests. That would test the claim that the flood is a queue problem.