Banner object (1)

Hack and Take the Cash !

844 bounties in database
  Back Link to program      
GitLab logo
Hall of Fame



GitLab is committed to working with security experts across the globe to stay up to date with the latest security techniques. Feel free to inspect our source code __. If you have discovered a security issue that you believe we should know about, we’d welcome working with you. Please let us know about it and we'll make every effort to quickly correct the issue.


GitLab will make a best effort to meet the following SLAs for hackers participating in our program:

  • Time to first response (from report submit) - 1 business day
  • Time to triage (from report submit) - 5 business days, depending on the current report volume. An estimated time to triage will be included in the first response.
  • Time to bounty (from triage) - between 5 and 90 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.

Please refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.

In scope


Our rewards are based on impact to our customers, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.

Critical (9.0 - 10.0) | High (7.0 - 8.9) | Medium (4.0 - 6.9) | Low (0.1 - 3.9)
$20,000 | $10,000 | $3000 | $1000

The indicated amounts represent upper bounds for the corresponding level of severity. For example, a medium severity issue will be awarded between $1000 and $3000, a high severity issue between $3000 and $10,000, etc.

For reports with critical, high, or medium severity we pay $1000 at the time the report is triaged. The remainder, if any, will be paid when the report is resolved or 90 days after triage, whichever happens earlier.

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.

How severity is determined

GitLab reserves the right to make a final decision regarding the severity of a reported finding. Upon receipt of the finding, we will conduct an internal investigation and determine the severity of the finding according to the following guidelines:

  • Critical (9.0-10.0) - the finding impacts > 50% of our customer base.
  • High (7.0-8.0) - the finding impacts many customers in our customer base.
  • Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.
  • Low (0.1 - 3.9) - the finding impacts no customers in our customer base.

Rules of Engagement, Testing, and Proof-of-concepts

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:

  • Generating abuse requests
  • Submission of support, sales or other requests to 3rd party systems
  • Mass creation of users, groups, and projects
  • Typosquatting or other namesquatting
  • Spam-like or other high volume activity

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 available at __and __. 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.

Out of scope

  • Automated scanning of any kind
  • GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).
  • Subdomains on that are out of scope are:
    • Static website
    • Public Information
    • *
    • * (Note the letter p at the end of gitlap)
  • User content on (for example, a user that is not using proper permissions on their projects containing sensitive information)
  • Self-hosted installs of GitLab CE and GitLab EE customers
  • Intentionally public information and hosts, for example, __
  • Attacks requiring physical access to the victim's computer
  • Man-in-the-middle attacks
  • Social engineering, phishing, or other fraud including but not limited to:
    • internationalized domain name (IDN) homograph attacks
    • Right-to-left (RTL) Ambiguity, RTL Override (RTLO)
    • SPF and DKIM issues
    • HTML content injection
    • Tabnabbing
  • Employee computer compromise
  • Missing Security Headers (eg. HSTS, CSP)
  • Missing Secure Flags on Cookies
  • SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)
  • CSRF without any security impact
  • User and project enumeration/path disclosure unless an additional impact can be demonstrated
  • Rate Limiting (unless it constitutes a significant risk)
  • Side-channel timing attacks
  • Text injection is eligible only on sensitive pages (for example, settings or authentication pages)
  • Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab

Reports of broken links

We appreciate reports of broken links that are susceptible to hijacking on our website and in our documentation. However, to prevent from being flooded with broken link reports we do not close these reports as "Resolved" but rather as "Informative". Broken links to script sources or other files that could result in script execution are treated as vulnerabilities.


All Resolved reports will be made public via issues on 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.


We believe in recognizing the work of others. If your work helps us improve the security of our service, we'd be happy to acknowledge your contribution in our Hall of Fame.


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.

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Eligibility for Participation

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 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.


If you have suggestions for improving this program, please let us know at

Our Process and Further Information

For more details on the process the GitLab Security Team follows when working
with HackerOne reports, please see our handbook __.
This includes further details on our triage and award review process.

In Scope

Scope Type Scope Name

Your Own GitLab Instance








Out of Scope

Scope Type Scope Name













This program have been found on Hackerone on 2016-02-06.

FireBounty © 2015-2019

Legal notices