Bug bounty platforms are a strange thing to audit. They are software built to receive vulnerability reports, which means the people operating them are unusually well equipped to judge your finding, and unusually likely to have already thought about the obvious cases.
I spent time with Gerobug, an open-source platform for running bounty programs, and came away with two confirmed issues, each with a live proof of concept.
Confirming before reporting
The first rule of reporting against a project like this is that a proof of concept is not optional. A description of a suspected flaw is a conversation. A request and response that demonstrate it is a finding.
Both issues were reproduced against a running instance before anything was written up. That took longer than finding them.
The disclosure path
With a project that has a CVE Numbering Authority arrangement, the path is: report privately, agree on the issue, let the maintainer patch, then publish. Two reservation requests were filed with MITRE:
- CAN-2026-2032157
- CAN-2026-2032158
A security advisory was published on GitHub alongside the fixes.
The CAN IDs are reservation requests rather than assigned CVE records, which matters when you write about them. Saying "CVE" before the number is assigned is how researchers lose credibility.
What I took from it
- Open-source tools that handle sensitive data deserve the same scrutiny as commercial ones.
- A reproduction is worth more than a paragraph of theory, every time.
- Disclosure is a project management exercise as much as a technical one. Timelines, reminders, and a clean public write-up are part of the work.
The advisory and the tooling are on my GitHub if you want to read the detail.