Table of contents
15
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: Most bug bounty report advice stops at “write clear steps to reproduce.” A real engineering team’s own published numbers show something sharper: 70% of their reports get rejected before a human ever reproduces anything, because an AI analysis pass filters them first.
- Elastic’s HackerOne program received over 1,390 reports in the first half of 2026 alone, more than its full-year totals for 2024 and 2025 combined, and it now runs HackerOne’s AI triage plus its own Claude-based pipeline before a human engineer spends time on most of them.
- 70% of reports never reach reproduction. They’re rejected at the analysis stage, Elastic’s own published breakdown, not an industry estimate.
- The AI agrees with the human decision 85% of the time, measured against 764 known-outcome reports, and a separate adversarial review catches problems in roughly 15% of the remaining cases before they reach a person.
- Early calibration had a real failure mode worth knowing: the system adopted the report’s own framing in over 30% of analyses instead of independently verifying it, meaning a report written with confident, specific language was more likely to get believed, correctly or not.
- HackerOne’s platform-wide numbers back up the urgency: average resolution time across all severities dropped from 135 to 62 days in the 2026 Hacker-Powered Security Report, but the backlog of valid, unresolved findings grew 131% over the same period, so speed at writing the report matters more than ever for getting it noticed at all.
Every bug bounty report guide tells you to write clear reproduction steps. That’s true and it’s also not the part most hunters are getting wrong anymore. The part worth understanding now is who, or what, actually reads your bug bounty report first.
Elastic’s security team published a detailed account of how they actually handle the volume: HackerOne’s own AI triage system runs first, and only reports it marks for further review reach Elastic’s own pipeline, an eight-stage Claude-based analysis followed by a separate adversarial review that independently challenges the first pass’s conclusions. Reports that clear both stages get reproduced in sandboxed Stack environments. A human makes the final call on every single report, but most reports don’t get a human’s full attention until they’ve already survived two automated filters.
The number that should change how you write: 70% of the bug bounty reports Elastic receives are rejected at the analysis stage and never reach reproduction at all. That’s not a vague industry estimate. It’s a specific team publishing their own funnel.
This isn’t unique to Elastic. HackerOne’s AI runs across the platform before it ever reaches a specific program’s own process, which means some version of this filtering is already happening to your reports on other HackerOne programs too, whether or not the program has published its own numbers.
Elastic’s own write-up is specific about what fails here, and it’s a useful checklist precisely because it’s drawn from real submissions, not hypothetical mistakes:
None of these require AI to reject. A careful human triager would catch them too. What’s changed is that they now get caught before a human spends the 30 to 60 minutes Elastic says a senior security engineer typically devotes to a bug bounty report that does reach them.
This is the detail most bug bounty report guides miss entirely, and it cuts both ways for you as a hunter. Elastic’s own calibration data showed that early versions of their AI analysis adopted the bug bounty report’s own language and framing in over 30% of cases, instead of independently verifying the claim. A bug bounty report written with confident, specific, technically precise language was more likely to be believed on its stated terms, correct or not.
The system also had category-specific weaknesses worth knowing if you’re submitting in these areas: it was too skeptical of cross-site scripting reports specifically, generating false negatives there, while producing more false positives on injection-class findings. Access control was, in Elastic’s own words, the hardest category for the system to judge correctly.
What this means practically: write your impact section the way you’d want an automated reviewer, not just a skeptical human, to read it. State the actual exploitability plainly and specifically rather than relying on alarming language to carry a weak technical claim, because specificity is what both a careful human and (per Elastic’s own data) an AI reviewer actually respond to.
Strip away the AI-triage layer and the baseline requirements for a bug bounty report, which HackerOne states directly in its hacker documentation, haven’t changed. They’re still the foundation everything above builds on:
HackerOne’s own checklist before you submit: confirm you can reproduce it with your own written steps, confirm the impact is explained clearly, attach supporting material (screenshots, a short recording, or a payload snippet), and format logs and code in actual code blocks rather than pasted plain text. Check for duplicates and confirm scope before any of that.
Platform SLAs give you a real number to hold programs to, and a sense of when a nudge is reasonable versus premature:
Put together: triage teams are faster per bug bounty report than they used to be and still falling behind on total volume. A bug bounty report that’s easy to validate quickly, the kind this article is describing, has a real, measurable advantage in that environment over one that technically has a valid bug buried in unclear writing.
Combine HackerOne’s baseline requirements with what Elastic’s data shows actually gets a bug bounty report rejected or misjudged, and a stronger structure emerges:
# A reproducible request beats a paragraph describing one.
curl -s -X POST https://target.example.com/api/v1/profile \
-H "Authorization: Bearer <low-priv-token>" \
-H "Content-Type: application/json" \
-d '{"user_id": "<victim-id>", "bio": "<script>alert(document.domain)</script>"}'
# Expected: 403, bio field rejects script tags per the program's CSP
# Actual: 200, stored and rendered unescaped on GET /profile/<victim-id>We build an AI agent, so take this section as exactly that, not a neutral recommendation. What Elastic’s data actually shows is instructive for anyone running an AI agent against bug bounty targets, not just Elastic’s own triage pipeline: a model reviewing your work can adopt your framing instead of independently verifying it, in both directions. If your agent drafts a finding with confident language around a weak technical claim, that confidence doesn’t make the claim true, for a human triager or an automated one.
Our AI exploit development and agentic pentesting coverage goes deeper on validating agent-generated findings before you trust them, which is the same discipline Elastic’s own calibration data argues for on the triage side. XHack’s own findings carry reproduction steps, the exact request, and a recommended fix by design, structured close to what HackerOne’s own documentation asks for, but our terms are explicit that AI output can be wrong, and you’re still the one who verifies a finding is real before it goes in a report with your name on it.
Some do, and it’s documented, not speculative. Elastic has published a detailed account of running HackerOne’s own AI triage alongside a custom Claude-based pipeline, filtering 70% of its bug bounty reports out at the analysis stage before any human reproduction work happens. HackerOne’s AI triage runs platform-wide, so some filtering likely applies to reports on other programs too, even ones that haven’t published their own numbers.
Based on Elastic’s published breakdown, the largest recurring categories are information disclosure in already-public open-source code, behavior that’s working exactly as designed, and volumetric denial-of-service reports, roughly 40% of the DoS submissions Elastic receives fall in this last category and are explicitly out of scope.
Bugcrowd’s own standard is 7 business days on a Bugcrowd-managed engagement. HackerOne’s 2026 platform data shows critical findings now average about 30 hours just for validation, improved from past years, though the overall backlog of unresolved valid findings has grown 131% as report volume outpaces remediation capacity across the industry.
It can backfire if the underlying finding is weak. Elastic’s own calibration data found its early triage system adopted a report’s stated framing instead of independently verifying it in over 30% of analyses. Write impact sections that are specific and technically accurate, not just confident, since both human and automated reviewers respond to real specificity, not tone.
Both where you can. HackerOne’s own documentation lists screenshots, short recordings, and payload snippets as supporting material that strengthens a report, on top of, not instead of, clear written reproduction steps a reviewer can follow without needing to watch anything.
HackerOne’s own example of a weak title is “XSS in web app.” A strong one names the exact vulnerability class and its location, like “Stored XSS in user profile field allows script execution on profile view.” Specificity in the title saves a reviewer, human or automated, from having to read the full report just to categorize it.
Write your next bug bounty report for the reviewer you’re actually going to get, and increasingly that’s an automated analysis pass before it’s a person. The fundamentals HackerOne has always asked for, a precise title, numbered reproduction steps, a real impact statement, haven’t changed. What’s changed is that skipping them now gets your report filtered out before a human ever sees the bug you actually found.
Confirm your version and scope up front in every bug bounty report, make your impact section specific rather than dramatic, and pre-empt the categories real triage data shows get auto-rejected. That’s not a trick to beat the system. It’s the same discipline that was always supposed to separate a good report from a wasted one, just with real numbers behind it now.
Categories
Related articles
