huntr.dev - the place to protect open source
Get recognised for protecting millions of developers
Visit the platform or continue reading...
About • Disclose • Fix • Discuss • Links • Updates • Community
huntr is a bug bounty platform developed by 418sec. We provide the open source community a way to learn and master open source security with real world practice on packages being utilised by millions of developers and services around the world.
This repository is an open and freely available database for all of the disclosures we have received from the open source community. We display these disclosures on our platform for you to learn about, attempt a fix and discuss with others.
You already have what it takes. Keep reading to learn more on how to disclose a vulnerability, submit a fix and share your opinions with us.
If you want to do a bit more reading around the platform and our mission, take a look at:
For the best experience when disclosing a vulnerability with us, sign up to the platform using your GitHub account.
Before disclosing a vulnerability, you should fork the repository and familiarise yourself with the contents of your new repo. You can fork by clicking here:
The bounties folder holds all previous disclosures and is also the location where new disclosures are added. Inside the bounties folder, each directory represents a package manager. These include:
Within each of these folders, you will find the names of packages that are served by these package managers. For example, bounties/npm/yup refers to:
Some package managers (i.e. owner/name, e.g. intervention/image. Where this is the case, the package directory assumes the following structure:
bounties
- packagist
- intervention
- image
Otherwise, it will follow:
bounties
- npm
- yup
Inside of each package directory, there will be a numbered list of directories starting at 1. This number is the identifier for the vulnerability/disclosure. For example, bounties/npm/yup/1 is the first disclosure in our database for yup.
This number, as well as the directory, refers to the respective vulnerability on the platform. The contents of the files inside a directory location will be used to generate the content for the platform vulnerability page:
https://huntr.dev/bounties/1-npm-yup
Each new and unique disclosure should iterate on this number, if the package for a specific package manager does not already exist.
Now that we have covered the basics of the vulnerability database, we can now submit a disclosure...
Each disclosure is made up of two files:
vulnerability.json and a README.md
The vulnerability.json contains all meta-data related to the vulnerability or disclosure. You can find a template below for the vulnerability.json which should be filled with relevant information. The README.md is a custom description of the disclosure that will appear on the platform. It is rendered with a simple Markdown processor that includes basic styling - similar to GitHub Flavoured Markdown. You can be as creative and artistic with your README.md as you please. These files are created by a discloser, within an existing or new package manager and package of choice.
For example, if you wanted to disclose a vulnerability in:
...you will create two empty files on your personal fork:
bounties/npm/lodash/1/vulnerability.jsonbounties/npm/lodash/1/README.mdYour vulnerability.json must take the following format to get accepted:
{
"PackageVulnerabilityID": "",
"DisclosureDate": "",
"AffectedVersionRange": "",
"Summary": "",
"Contributor": {
"Discloser": "",
"Fixer": ""
},
"Package": {
"Registry": "",
"Name": "",
"URL": "",
"Downloads": ""
},
"CWEs": [
{
"ID": "",
"Description": ""
}
],
"CVSS": {
"Version": "",
"AV": "",
"AC": "",
"PR": "",
"UI": "",
"S": "",
"C": "",
"I": "",
"A": "",
"E": "",
"RL": "",
"RC": "",
"Score": ""
},
"CVEs": [""],
"Repository": {
"URL": "",
"Codebase": [""],
"Owner": "",
"Name": "",
"Forks": "",
"Stars": ""
},
"Permalinks": [""],
"References": [
{
"Description": "",
"URL": ""
}
],
"PrNumber": ""
}Furthermore, the contents of each key must have a value that follows the definition table:
| Field | Definition | Example |
|---|---|---|
| PackageVulnerabilityID | Numerical incrementing ID | 1 |
| DisclosureDate | Disclosure submission date | 2020-12-01 |
| AffectedVersionRange | Vulnerable version/s of the package | * or 1.0.0 |
| Summary | Summary of the vulnerability | Prototype Pollution |
| Contributor.Discloser | GitHub ID of the discloser | No input required... |
| Contributor.Fixer | GitHub ID of the fixer | No input required... |
| Package.Registry | Name of package manager/registry | npm |
| Package.Name | Name of the vulnerable package | lodash |
| Package.URL | URL to the package in the registry | https://www.npmjs.com/package/lodash |
| CWEs.ID | Common Weakness Enumeration ID of the vulnerability | 400 |
| CWEs.Description | Name of the CWE ID | Failure to Sanitize Input |
| CVSS.Version | Version of CVSS Calculator | 3.1 |
| CVSS.AV | Attack Vector | P |
| CVSS.AC | Attack Complexity | H |
| CVSS.PR | Privileges Required | L |
| CVSS.UI | Privileges Required | L |
| CVSS.S | Scope | L |
| CVSS.C | Confidentiality | L |
| CVSS.I | Integrity | L |
| CVSS.A | Availability | L |
| CVSS.E | Exploit Code Maturity | L |
| CVSS.RL | Remediation Level | L |
| CVSS.RC | Report Confidence | L |
| CVSS.Score | Common Vulnerability Scoring System | 9.8 |
| CVEs | Common Vulnerabilities and Exposures (CVE) | ["CVE-abc-123"]- optional |
| Repository.URL | GitHub Repository URL | https://github.com/418sec/huntr |
| Repository.Codebase | GitHub Repository Codebase | ["JavaScript"] |
| Repository.Owner | GitHub Repository Owner | 418sec |
| Repository.Name | GitHub Repository Name | huntr |
| Permalinks | GitHub Permalinks | ["https://github.com/418sec/huntr/blob/staging/.gitignore#L1"] |
| References | Links or Articles relating to vulnerability | {
"Description": "Blog",
"URL": "https://huntr.dev/blog"
} |
Data Definition Table for vulnerability.json
For more information on the requested meta-data, you can refer to the following resources:
- CVE - Common Vulnerabilities and Exposures
- CVSS - Common Vulnerability Scoring System
- CWE - Common Weakness Enumeration
- How to create a permalink with GitHub
The README.md file is fully customisable, but you can use the following template:
# Description
`myPackage` is vulnerable to `a scary vulnerability`.
This exploit may result in the modification of..., which may result in...
# Proof of Concept
1. Create the following PoC file:
{Show PoC code here...}
2. Execute the following commands in another terminal:
{Show terminal commands here...}
3. Check the Output:
{Show result of execution here...}
N.B - ensure that any hyperlinks or URLs are added to the References array in the vulnerability.json
If you are up to this point, great job! You can now go ahead and open a pull request from your fork to 418sec/huntr:staging. Make sure that you have submitted only one vulnerability.json and README.md per pull request. If you do this properly, a 
All previous disclosure PRs are labelled with:
Before being accepted, your vulnerability.json will go through some checks to ensure a minimum level of quality. If your disclosure fails these checks, you will be able to view the results of these checks at the bottom of your PR.
Once your disclosure has passed the minimum quality checks, it will be automatically merged and be visible on the platform under the URL:
https://huntr.dev/bounties/${PackageVulnerabilityID}-${Package.Registry}-${Package.Name}Need more help? Take a look at our video walkthrough for more information...
For the best experience when fixing a vulnerability with us, sign up to the platform using your GitHub account.
All of our submitted disclosures will be displayed on the bounties page on the platform. You can filter by programming language and view disclosures ordered by most recent, first.
To start working on a fix, visit any bounty page and click the Fork and Fix button. This will only be visible if you have signed up with your GitHub account. This will create a fork of a 418sec GitHub repository; we have forked the upstream repository so that we don't bother the true maintainer with heavy discussion threads on their repository.
For example:
lodash/lodash
|_418sec/lodash
|_YOUR-USERNAME/lodash
Once you have forked through our platform, you will be provided a git clone command. With this, you can start working on your fork and building your fix, woohoo! 🎉
Once you are happy with your fix on your forked repository, you can now open up a pull request from your fork to the 418sec repository.
We encourage you to reference your pull request submission on the original disclosure through the comments section on the platform. To do this, simply copy your GitHub PR URL into the comments section. This will automatically setup a linked reference to your PR. This will give you the opportunity to get community feedback on your fix and learn with others on their submissions too.
We encourage everyone to engage in the discourse for vulnerability disclosures and fixes through our platform. To sign up, click here. You will find a comments section on each bounty page where you can express your thoughts and learn with others.
If you have any feedback about this repository or the platform, get involved with the conversation on our Discord. Join our growing community today!
You may find the following links helpful:
Not sure what to write in the description of your pull request? You can use our PR (pull request) templates to help you:
Turn your notifications to watching to keep yourself up-to-date. To show us some love, give us a star!
You can find community-based projects here: