
GitLab
External Program
Submit bugs directly to this organization
We have different rewards depending on the business impact of each asset. A more complete description of each asset will be in the scope section, but in general GitLab.com and all our products' source code is rewarded the highest, then non-production environments have reduced bounties and our static websites have the lowest payouts.
See the Rewards section above for our bounty ranges. For reports with critical or high severity we pay $1000 at the time the report is triaged, and for medium severity reports we pay $500. The remainder, if any, will be paid as soon as the severity has been fully analyzed internally. The calculator we use to calculate CVSS-based bounty amounts is accessible to everyone.
Reports about intended behavior resulting in an update of our documentation will be rewarded with a $100 bounty, as long as this update is security related.
GitLab assigns CVE identifiers to vulnerabilities affecting GitLab products. While the CVSS score for those should generally align with the severity set in the HackerOne report, sometimes they will differ depending on our assessment of the business impact based on existing mitigations, the sensitivity of the impacted data, and number of impacted customers among other factors.
While we try to be as consistent as possible with rewards, our program is also evolving and rewards may change accordingly to how our program evolves with time.
For valid reports for which the author can't accept monetary rewards, we offer to plant trees in our GitLab forest on their behalf.
Reporters which have submitted three or more valid findings to our program are eligible to receive a one year self-hosted Ultimate license supporting up to five users. If you believe you're eligible, please request the Ultimate license via a comment in one of your reports mentioning the assigned security engineer, and include links to your other two valid reports. Once verified, the license will be sent to your [username]@wearehackerone.com email address. Any further valid submissions in that year will extend you the next year's license for free too.
Upon receipt of the finding, we will conduct an internal investigation to understand the full impact of the vulnerability. We then assess the severity using the Common Vulnerability Scoring System (CVSS) and score according to the guidelines you can see in the "help & definitions" section of our CVSS calculator. Note that even if GitLab.com allows self-registration, most GitLab instances in the wild don't -- which makes vulnerabilities that are exploitable without authentication a lot more impactful. For this reason, any vulnerability that requires an account will not be scored with "Privilege Required: None".
Reports for security issues that aren't vulnerabilities in our systems and where CVSS isn't appropriate (for example a leaked confidential document) will receive a discretionary bounty based on our assessment of the impact of the finding.
We collaborate with HackerOne Triage Service for quickly identifying valid and impactful reports. By-passing the HackerOne triage service by opening issues in GitLab project or reaching out to GitLab team members directly on reports or via other mediums is a violation of HackerOne Code of Conduct (CoC) and might attract CoC enforcement actions.
CVSS scores and bounty awards are determined by the consensus of the GitLab Bug Bounty Council. Multiple team members review and validate the CVSS for each triaged report to ensure accurate and impartial assessments. Reporters can raise concerns if they believe a CVSS metric has been misjudged. However, the final decision on CVSS scoring and bounty awards rests with the council.
For different attack vectors that result in the same mitigation, GitLab reserves the right to reward the first report that is validated for that fix. All subsequent reports that are addressed by that mitigation will be considered as duplicates, regardless of the attack vector.
When researching security issues, especially those which may compromise the privacy of others, you must use only test accounts in order to respect our users’ privacy. Accessing private information of other users, performing actions that may negatively affect GitLab’s users (e.g., spam, denial of service) will disqualify the report. Activity that is disruptive to GitLab operations will result in account bans and disqualification of the report. Examples of disruptive activity include, but are not limited to:
Sending reports from automated tools without verifying them will immediately disqualify the report.
Disruptive activity such as that listed above can be researched freely on your own installation of gitlab. GitLab is an open-core company, with the source code powering GitLab.com available in the main GitLab Project. You are encouraged to install your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.
We strongly encourage security testing on your local GitLab Development Kit (GDK) instance rather than GitLab.com for most vulnerability research. The GDK provides:
For Denial of Service (DoS) vulnerabilities specifically: Testing and demonstrating DoS impact on a local GDK instance can be problematic. If you need to demonstrate DoS impact, we recommend testing on a self-managed GitLab instance with specifications and resources equal to or greater than the self-managed GitLab installation requirements. Never test DoS vulnerabilities on GitLab.com.
For vulnerabilities requiring GitLab.com production architecture, you must use test accounts created with your HackerOne email alias ([email protected]). Never test against projects, groups, accounts, or instances you do not own.
Behave professionally. Failure to follow HackerOne's policies, such as the Code of Conduct, may result in the report being ineligible for a bounty at GitLab's sole discretion, in addition to any enforcement action HackerOne may decide to take.
vulnerable-subdomain.example.com/$UUID-poc.txt where $UUID is a hard-to-guess value.When testing on GitLab.com, your @wearehackerone.com address must be associated with the testing account. If separate accounts are necessary, you can use an alias. This will help us separate testing from other forms of abuse, and help inform the decision of blocking an account. Note that this does not provide immunity and the Rules of engagement must be followed at all times.
Please keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.
Please don't request Developer access to our projects, including the GitLab Community Forks group. While it can indeed be a security risk for the company that a random person joins those projects, it is something the security team handles and we don't want bug bounty hunters to test those workflows as it creates unnecessary noise for our teams.
GitLab will make a best effort to meet the following SLAs for hackers participating in our program:
The only appropriate place to inquire about a HackerOne report's status is on the report itself. Please refrain from submitting your report or inquiring about its status through additional channels including any other unrelated HackerOne report, as this unnecessarily binds resources in the security team.
All GitLab Inc. products are in scope unless explicitly noted otherwise.
Testing on subdomains that are neither explicitly in scope nor out of scope isn't encouraged, but if you can find a vulnerability with business impact on such a subdomain please report it. We normally close sufficiently clear reports as Informative so there will be no negative effect on your reputation score if we decide that it's out of scope. However, remember that GitLab subdomains that are running third party services are strictly out of scope.
We release new features every month. You can learn more about our release process, see the latest monthly release blog post and see what's coming in future releases. If you're bug hunting, might we suggest a newly released feature? 😉
Reports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:
This does not include websites of third party software and services and only includes dependencies & packaged software.
We only accept prompt injection related vulnerability reports where there is demonstrable impact beyond its current security boundary. GitLab continues to develop security protections for Duo and agentic systems which can be referred to here. Stay tuned for further iterations to the Bug Bounty program around AI related vulnerabilites in the near future.
gitlab.cn and the JiHu-specific GitLab distribution which are property of GitLab Information Technology (Hubei) Co., Ltd. (JiHu), security issues in those products should be reported to [email protected]/api/v4/user API). If unable to find the token owner's email address you can disclose leaked tokens by creating a confidential issue assigned to the token owner in the project where the token was leaked)*.runway.gitlab.net endpoints*.gitlab-private.org_gitlab_session token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.new-sentry.gitlab.net. As per sentry document:
The secret part of the DSN is optional and effectively deprecated. While clients will still honor it, if supplied, future versions of Sentry will entirely ignore it.
All Resolved reports will be made public via issues on GitLab.com 30 days after releasing a fix. We will redact all information we consider sensitive (such as cookies or tokens), but do not hesitate to let us know if additional content should be hidden. If you also want the report to be disclosed via HackerOne, please request disclosure.
Informative or self-closed reports that are determined to be bugs or new feature requests with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.
The Gold Standard Safe Harbor applies.
Practices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's Acceptable Use Policy.
You are responsible for complying with any applicable laws. You are not eligible to participate in this program if you are currently an employee of GitLab, Inc. or any of its subsidiaries. Reports from former employees, immediate family of current employees, or other associates of GitLab.com that may present a conflict of interest of the goals of the program will be more thoroughly reviewed and may not qualify for the stated bounty awards at GitLab's discretion.
GitLab is regularly looking to hire talented security professionals. Learn more at our jobs page.