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 any public repository on

With our responsible disclosure policy, we fully disclose any vulnerability reported to us directly to the maintainer. To this effect, participants can rectify any potential vulnerability in the repository.

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, 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 repository 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


1. Disclose

All vulnerability disclosures must go through our form.

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.

2. Validate

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 report will be made public to our community for patching. Once the first patch is suggested, the maintainer will be notified again, and can begin to engage with security researchers that have submitted patches.

If the maintainer perceives the vulnerability to be both valid, and is happy with a suggested patch, it will be made available immediately for distribution to the open source community, with all contributors credited.

3. Patch

On the disclosure of a new vulnerability, a fork of the vulnerable repository is created. To submit a fix, security researchers are encouraged to submit a patch against our fork. On the submission of a fix, the maintainer will be contacted in the pull request, and will be asked to validate the suggested patch.

If the maintainer is happy with the suggested patch, they can approve the submission. This patch will then be made available for distribution.

4. Publish

We look to have a CVE (Common Vulnerability Enumeration) assigned to every vulnerability, containing all requisite information as defined by CVE.

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 We look to respond to support queries as soon as possible.

If you believe that any of the CVEs created have incorrect or invalid information, please feel free to contact us.