Introduction
Thank you for submitting a vulnerability report to the H1 platform. This guide is designed to help you understand what happens after you click submit - from initial triage through final resolution and potential disclosure.
Understanding the process helps set realistic expectations and ensures a smooth, collaborative experience between researchers and our security teams.
š What This Guide Covers:
The updated disclosure process and what it means for you as a researcher
Each stage of the review pipeline, step by step
Anticipated response and resolution timelines
How to communicate effectively with the triage team
Common questions and escalation paths
What to Expect: The Review Pipeline
After submitting your report, it enters a structured review pipeline. Each stage is handled by dedicated team members and follows defined service-level objectives (SLOs). Below is an overview of what happens at each stage.
Response & Resolution Timeline
The table below outlines each stage of the review process, the expected timeframe, and the activities that occur. Placeholder values will be updated once official SLOs are confirmed.
Stage | What Happens | Typical Timeline |
Initial Acknowledgment | You receive an automated confirmation your report was received. A team member is assigned to review. | Immediately upon submission |
Triage & Validation | Security Analysts, either from the customer or HackerOneās Trage team, your submission for validity, severity, and scope. You may receive follow-up questions. | ~2-4 business days after submission |
Program Review | The affected program or team assesses the vulnerability and confirms impact. Internal escalations may occur. | ~4-10 days after validation |
Bounty Decision and Award | If eligible, your bounty is assessed and awarded. You'll receive a notification with the final determination. | Bounties paid ~2 weeks after submission |
Remediation | A fix is developed and tested. Critical/High severity issues are prioritized. You'll be notified when resolved. |
|
Disclosure | Once resolved, public disclosure may be requested via the Disclosure Request process described above. If the customer initiates disclosure, you will be informed in advance. |
|
ā ļø Note on Timelines: Timelines vary based on report complexity, program responsiveness, severity classification, and triage volumes.
Communicating with the Triage Team
Clear, professional communication helps your report move through the pipeline efficiently. Here are the best practices for engaging with the HackerOne triage team after submission.
Submitting a Quality Report
A strong report is comprehensive yet concise. It should give the triage team everything they need to verify the vulnerability without unnecessary noise or back-and-forth. At a minimum, your report should:
Provide a clear, descriptive title: Summarize the vulnerability specifically. For example, "Stored XSS in user profile field allows script execution on profile view" is far more useful than "XSS in web app."
Include a strong proof of concept
Be marked accurately if a report is critical and time-sensitive at the point of submission
Demonstrate clear, reproducible impact with step-by-step reproduction: Number your steps clearly, include relevant URLs, affected parameters, and any user roles required to trigger the issue. Screenshots, screen recordings, and code snippets are strongly encouraged.
Account for real-world mitigations and context
Provide a clear Impact Assessment: Describe what an attacker could realistically do with this vulnerability and what damage it could cause. Don't assume the reader will infer it.
Describe expected vs. actual behavior: Clearly describe what should happen and what actually happens.
Before you submit, run through this quick checklist:
Can the vulnerability be reproduced using the steps you've provided?
Is the impact clearly explained?
Have you included supporting materials where helpful, including proof of concept?
Are code snippets and logs formatted properly (use code blocks and markdown)?
Have you confirmed the issue is within program scope?
š Report Quality Resources
For a full pre-submission checklist and examples of strong reports, refer to HackerOne's Quality Reports guide.
Do's and Don'ts
ā DO: Respond promptly to follow-up questions from the triage team to avoid delays.
ā DO: Provide clear reproduction steps, screenshots, or proof-of-concept code if requested.
ā DO: Use the report comments section for all communication related to your submission.
ā DO: Be patient during peak periods ā the team handles high volumes across many programs.
ā DO: Request Hacker Mediation if you need support with a report dispute after attempting to resolve the issue directly on the report. Provide clear context about the disagreement and why you believe mediation is needed.
ā DON'T: Submit duplicate reports for the same vulnerability while one is still open.
ā DON'T: Attempt to contact program staff outside of the HackerOne platform.
ā DON'T: Publicly disclose vulnerability details before the coordinated disclosure window or make threats of disclosure.
ā DON'T: Retest or probe a vulnerability without prior approval from the program.
Escalating a Concern
If you believe your report is being mishandled, has gone unacknowledged beyond the expected response window, or you have a dispute with a program decision, you can escalate through the following path:
Step 1: Post a comment on your report requesting a status update.
Step 2: If no response within 5 business days, use the Request mediation option in the report.
Bounty & Recognition
If the program offers bounties, eligible reports will be assessed after the vulnerability is triaged and validated. The award amount is determined by the severity, impact, and quality of the report.
Bounty Eligibility
The report must be within the defined scope of the program.
The vulnerability must be reproducible and previously unknown.
The submission must not violate the programās rules of engagement.
The researcher must maintain confidentiality until public disclosure is approved.
Payment Timeline
Bounty payments are typically issued after the vulnerability is confirmed and resolved. Specific payment timelines vary by program.
š° Bounty Payment Details
For information on payment methods, tax documentation requirements, and payout schedules, read our Payment Preferences doc.
Updated Disclosure Process
HackerOne is committed to responsible, coordinated disclosure that respects both researcher contributions and the security needs of affected organizations. The updated disclosure process reflects our ongoing effort to make this experience fair, transparent, and timely.
How Disclosure Works
HackerOne's disclosure process is designed to balance public transparency with program control over what information is shared - and when. Both researchers and program members may initiate a disclosure request, but formal program approval is always required before anything becomes public.
To request disclosure:
The report must be in a closed state.
Select Request Disclosure from the action picker at the bottom of the report.
Choose between Full disclosure (full report contents, including comments and attachments) or Limited disclosure (summary and activity timeline only, with comments and attachments hidden).
Include a comment explaining your reason for the request.
After a disclosure request has been made, the program team can choose to publicly disclose the report and may also change the disclosure option between Full and Limited.
Researcher Guidance and Responsibilities
Engage in Good Faith Disclosure practices (detailed here). Good faith disclosure practices protect both researchers and programs - they preserve trust, ensure vulnerabilities are handled responsibly, and uphold the credibility of the security community as a whole. As a researcher, you should:
Obtain explicit approval from the program team before any vulnerability details are made public. This applies to all closure statuses, including Informative, Duplicate, and Not Applicable.
Respect program timelines and avoid disclosing prematurely, even if a fix has already been implemented.
Escalate delayed disclosure requests through proper channels (HackerOne Support) rather than disclosing without following the defined processes.
Never use disclosure as leverage - threatening to disclose in order to pressure a bounty award or payout increase is a violation of the HackerOne Code of Conduct and may result in enforcement action, including permanent platform removal.
š Full Disclosure Policy & How to Request Disclosure
For complete details on HackerOneās coordinated disclosure policy, please refer to our Disclosure Guidelines.
For guidance on coordinated disclosure and how to navigate the disclosure process on HackerOne, refer to our Requesting Disclosure documentation.
What to Know about the Disclosure Timeline
Give programs time to review your disclosure request before following up. If a disclosure request you have submitted has been pending for more than 30 days without an update, escalate to HackerOne Support for assistance.
Programs configure one of three disclosure settings that affect how and when disclosure can occur:
Disclosure - A hacker can request disclosure for any closed report. If neither approved nor denied, reports in the Resolved state will automatically default to disclosure within 30 days.
Disclosure Requiring Mutual Agreement - A hacker can request disclosure for any closed report, but explicit approval from the program must be received regardless of report status before proceeding with disclosure. If no action is taken, the report remains private.
Disclosure Disabled - Disclosure is not permitted for any report, regardless of report status.
When in doubt about a timeline for disclosure, donāt hesitate to contact HackerOne Support for additional clarification.