A Report With 50 Comments Took Down HackerOne (2,500$ Bounty)

The bug itself was almost embarrassingly simple: HackerOne's report-to-PDF export had no cap on how much content it would try to render. Stack enough comments into a single report — in this case 50 comments at roughly 100KB apiece — and the resulting PDF ballooned past 20MB. Requesting that PDF at hackerone.com/reports/<report_id>.pdf meant the server had to generate all of it, every time, on demand.

That alone is just a slow endpoint. The actual vulnerability was what happened when that slow endpoint got hit repeatedly. A modest, almost boring request rate — one or two requests per second, from a single IP — was enough to start degrading response times across hackerone.com within seconds. No botnet, no distributed traffic, no exotic technique. Just a heavy, uncached operation triggered often enough that the server couldn't keep up, cascading into timeouts and 502/504 errors for unrelated users elsewhere on the platform.

To confirm this wasn't just local network flakiness or a self-inflicted illusion, the researcher checked from separate locations and IPs while the test was running and saw the same delays — real, externally visible degradation of HackerOne itself, not a self-DoS artifact.

What makes this case notable isn't just the bug — it's what happened after. HackerOne's initial triage response marked it ineligible for a reward, citing a DoS testing policy the reporter had, by their own account, actually followed: single IP, single user, no automated flooding, immediate stop once impact was confirmed, testing within allowed hours. The one gap was not stating the testing IP address up front. After the reporter pushed back and asked directly which specific policy line was violated, HackerOne reversed course and paid out $2,500 as an explicit exception — while noting future reports would need to follow the published rules more strictly regardless.

The eventual fix was rate limiting on the PDF endpoint. On retest, that held — but the reporter flagged the more durable fix: caching the rendered PDF, since a per-IP or per-account rate limit alone can still be worked around with multiple accounts or IPs hitting the same expensive, uncached render path.