Responsible disclosure policy
At huntr, we understand the importance of open source software, and the benefits it has for organisations and individuals around the world. We support an open source vulnerability disclosure program, where any member of the public can report vulnerabilities found in repositories on GitHub.com.
With our responsible disclosure policy, we follow a co-ordinated security process by default. We disclose all vulnerabilities directly to the maintainer. To this effect, participants can rectify any potential vulnerability in the repository privately, before sharing it with the public.
As part of our program, it is important that all contributors receive the recognition they deserve. Once a vulnerability has been fully disclosed, acknowledged by the maintainer, and subsequently patched, we credit all contributors involved for their crucial work in the process.
This policy strictly covers all public repositories on GitHub.com, with the following exclusions:
- Non-code level (e.g. network or physical) vulnerabilities
- Vulnerabilities in any service, product or repository owned or maintained by 418sec, or any of its subsidiaries
We take the security of maintainers, developers and organisations that use open source very seriously. In this light, we encourage all of our security researchers to:
- Follow all relevant laws when exploiting a vulnerability
- Perform thorough research and submit in-scope reports
- Use the identified methods of disclosure as defined in our policy
- Support disclosures with clear and simple details, including a proof-of-concept
If these guidelines are followed, we commit to:
- Recognise and credit the work of all contributors involved
- Support our security researchers in working with the maintainer to validate and remediate legitimate vulnerabilities
When the security researcher submits their vulnerability report, we will acknowledge receipt of this disclosure by sending them an e-mail. The e-mail will be sent to the address linked to their registered account. This report is private by default, and only the reporter and contacted maintainers can view the advisory.
Once a disclosure is submitted, the maintainer of the vulnerable codebase will be invited to validate or invalidate the vulnerability with the security researcher. If validated, the disclosing researcher will be rewarded a bounty and a CVE will be assigned to the advisory.
By default, maintainers are encouraged to patch the vulnerability themselves, and notify us of the relevant patch commit SHA. A bounty will then be rewarded to the maintainer that has patched the vulnerability. If needed, other researchers are welcome to submit patches through our platform.
To submit a fix, a researcher will provide us with a repository and branch name, indiciating where the patch exists. This will immediately notify the maintainer, where they can review the submitted fix and ultimately, decide if it patches the vulnerability. Once the maintainer confirms the upstream commit SHA for the patch, the related fixer will be rewarded a bounty.
We look to have a CVE (Common Vulnerability Enumeration) assigned to every validated vulnerability. A validated vulnerability is defined by explicit verification from a maintainer that the vulnerability as disclosed, affects the security of the repository.
To find a list of our previous advisories, please visit our hacktivity page.
We do not accept vulnerability disclosures over e-mail, but we encourage security researchers to contact us if they require any support or help in the process. Our team can be contacted at firstname.lastname@example.org. We look to respond to support queries as soon as possible.