Vulnerability Disclosure Standards
Coordinated disclosure protects both researchers and programs — they preserve trust, ensure vulnerabilities are handled responsibly, and uphold the credibility of the security community as a whole. These Vulnerability Disclosure Standards (aka Vulnerability Disclosure Guidelines) help define the structured process by which Community Members and customers can request disclosure of submitted vulnerabilities. Nothing in these guidelines is intended to contradict any of HackerOne's Community Member Terms and Conditions or the HackerOne Code of Conduct. Researchers must adhere to all of the below when requesting disclosure of submitted vulnerabilities:
- This Vulnerability Disclosure Standards
- HackerOne's Coordinated Vulnerability Disclosure framework
- The HackerOne Code of Conduct
- Individual program settings and policies when requesting disclosure of submitted vulnerabilities for both public and private programs.
Program Participation & Submission Process
Security Teams will publish a program policy outlining the scope of security research for their program and individual requirements and conditions for participating in the program, including terms related to confidentiality and disclosure. You should always carefully review this program policy prior to participating in a program, as they may supersede these guidelines in the event of a conflict. If you are unsure how a specific program policy applies, please contact HackerOne Support or your Hacker Success Manager.
If you believe you have found a vulnerability, please submit a Report to the appropriate program on the H1 Platform. The Report should include a detailed description of your discovery with clear, concise reproducible steps or a working proof-of-concept, but should not include third-party PII. If you don't explain the vulnerability in detail, there may be significant delays in the disclosure process, which is undesirable for everyone.
The Report will be updated with significant events, including when the vulnerability has been validated, when more information is needed from you, or when you have qualified for a bounty (if applicable).
Vulnerability Disclosure Process
The contents of the Report will be made available to the Security Team immediately, and will initially remain non-public to allow the Security Team sufficient time to publish a remediation. After the Report has been closed, public disclosure may be requested by either the Community Member or the Security Team. Next steps may differ, depending on the individual program's Disclosure Settings, but please keep in mind that a program's individual policy may include additional requirements.
Community Members may request disclosure of a closed vulnerability they submitted to a Customer program through this process. Disclosure may be full or limited, depending on the Customer's program settings.
- Disclosure Setting - Default: For programs with the "Disclosure" setting, if neither party raises an objection, the contents of the Report will be made public within 30 days if the Report state is "Resolved." Reports closed in any other state (e.g., Informative, Duplicate, Not Applicable, etc.) require mutual agreement.
- Disclosure Setting - Mutual Agreement: For public programs with the "Mutual Agreement" setting, the report may be publicly disclosed only if the Customer formally approves the Community Member's disclosure request. If the Customer rejects the disclosure request or does not respond to the request (subject to the "Last Resort" policy below), the report may not be disclosed. We encourage the Community Member and Security Team members to remain in open communication regarding disclosure timelines. If both parties are in agreement, the contents of the Report can be made public on a mutually agreed timeline.
- Last Resort: If a Security Team has not responded to a formal request for disclosure for 180 days despite reasonable follow up from the Community Member (at least once every 30 days), the contents of the Report may be publicly disclosed by the Community Member, unless otherwise prohibited by the program's policy. Any disclosure must adhere to the HackerOne Code of Conduct and cannot include third-party confidential or personal information.
- Disclosure Setting - Disabled: While the Community Member may request disclosure, the program's default position is that reports may not be publicly disclosed. Disclosure is not permitted for any report - regardless of report status (including Informative, Duplicate, and Not Applicable). If the Customer rejects the disclosure request or does not respond to the request, the report may not be disclosed.
When disclosure is permitted, complexity, security risks, and other factors of the vulnerability reported may require longer than 30 days to remediate. In these cases, the Report must remain non-public to ensure the Security Team has an adequate amount of time to address a security issue. We encourage Security Teams to remain in open communication with the Community Member when these cases occur.
Furthermore, if the Security Team has evidence of active exploitation or imminent public harm, Customer may immediately provide remediation details to the public so that users can take protective action.
Private Program
Some Community Members may receive invitations to private Programs. Participation in a private Program is entirely optional and subject to strict non-disclosure by default. Prior to accepting an invitation to a private Program, Community Members should carefully review any program policies and non-disclosure agreements required for participation. Community Members that intend any form of public disclosure should not participate in private Programs.
Public Recognition
You may receive public recognition for your Report if 1) you are the first person to file a Report for a particular vulnerability, 2) the vulnerability is confirmed to be a valid security issue, and 3) you have complied with these guidelines. If a Community Member prefers to remain anonymous, we encourage them to submit under a pseudonym.
Bug Bounty
Some Security Teams may offer monetary rewards for vulnerability disclosure. Not all Security Teams offer monetary rewards, and the decision to grant a reward is entirely at their discretion. The amount of each bounty payment will be determined by the Security Team. Bounty payments are subject to the following eligibility requirements:
- Because we're based in the United States, we aren't able to pay bounties to residents or those who report vulnerabilities from a country against which the United States has trade restrictions or export sanctions as determined by the U.S. Office of Foreign Assets Control (OFAC).
- Minors are welcome to participate in the program. The Children's Online Privacy Protection Act restricts our ability to collect personal information from children under 13 and we must take certain steps to ensure compliance with other applicable laws related to minors. Accordingly, you will need to claim your bounties through your parent or legal guardian if you are under 18.
- All payments will be made in U.S. dollars (USD) and will comply with local laws, regulations and ethics rules. You are responsible for the tax consequences of any bounty you receive, as determined by the laws of your country.
- It is your sole responsibility to comply with any policies your employer may have that would affect your eligibility to participate in this bounty program.
Definitions
Security Team: A team of individuals who are responsible for addressing security issues found in a product or service. Depending on the circumstances, this might be a formal security team from an organization, or a group of volunteers on an open source project.
Community Member: Also known as security researchers. Anyone who has investigated a potential security issue in some form of technology, including academic security researchers, software engineers, system administrators, and even casual technologists.
Report: A Community Member's description of a potential security vulnerability in a particular product or service. On HackerOne, Reports always start out as non-public submissions to the appropriate Security Team.
Vulnerability: A software bug that would allow an attacker to perform an action in violation of an expressed security policy. A bug that enables escalated access or privilege is a vulnerability. Design flaws and failures to adhere to security best practices may qualify as vulnerabilities. Weaknesses exploited by viruses, malicious code, and social engineering are not considered vulnerabilities unless the Security Team says otherwise in the program's policy.
Programs: Security Teams may publish a Program and Program Policy designed to guide security research into a particular service or product. If this program is private, your participation is entirely optional and subject to non-disclosure by default.
Contact
HackerOne is always open to feedback, questions, and suggestions. If you would like to talk to us, please feel free to contact us at via the HackerOne Support Portal or follow us on X (formerly Twitter) @Hacker0x01.
Changes to These Guidelines
We may revise these guidelines from time to time. The current version is 1.3 updated on July 27, 2026 and will always be at https://www.hackerone.com/disclosure-guidelines. If we make changes that we believe will substantially alter your rights, we will email you and prominently display a notice on our site 7 days before we make those changes.