[{"id":3773732,"new_policy":"# Rewards\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/install/) your own standalone instance for researching vulnerabilities. \n\nDue to an increase in low-quality AI-generated submissions, all reports must include one of the following reproduction artifacts: screen captures, videos, and logs showing vulnerabilities against your own GitLab installation. Reports without verifiable evidence may be closed as N/A.\n\n**We strongly encourage security testing on your local [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) instance** rather than GitLab.com for most vulnerability research. The GDK provides:\n- Access to the latest development features before public release\n- No rate limits or testing restrictions on your local instance\n- Safe environment for testing most vulnerability types\n- [GDK Security Testing Guide - link to create]\n\n**For Denial of Service (DoS) vulnerabilities specifically:** \nTesting 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](https://docs.gitlab.com/install/requirements/).\n**Never test DoS vulnerabilities on GitLab.com.**\n\nFor vulnerabilities requiring GitLab.com production architecture, you must use test accounts created with your HackerOne email alias (yourhandle@wearehackerone.com). **Never test against projects, groups, accounts, or instances you do not own.**\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe 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](https://docs.gitlab.com/user/duo_agent_platform/security_threats/). Stay tuned for further iterations to the Bug Bounty program around AI related vulnerabilites in the near future.\n\nBelow is a running table of known prompt injection vulnerabilities that are **out of scope** for the GitLab bug bounty program. Do not submit reports for these specific known instances.\n\n| Vulnerability  | Link |\n|---|---|\n| Duo Agentic Chat prompt injection vulnerability  | [#581264](https://gitlab.com/gitlab-org/gitlab/-/work_items/581264) |\n| Filename Injection in TRUSTED_INTERNAL Tools  | [#587934](https://gitlab.com/gitlab-org/gitlab/-/work_items/587934) |\n| Invisible Prompt Injection in Issues/MRs  | [#586481](https://gitlab.com/gitlab-org/gitlab/-/work_items/586481) |\n| Context Boundary Failure in GitLab Duo Agent Tools  | [#582995](https://gitlab.com/gitlab-org/gitlab/-/work_items/582995) |\n| TOCTOU and Prompt Injection in GitLab Duo \"Issue to MR\" Flow  | [#584107](https://gitlab.com/gitlab-org/gitlab/-/work_items/584107) |\n| Hidden Prompt Injection in AI Catalog Agents  | [#579778](https://gitlab.com/gitlab-org/gitlab/-/work_items/579778) |\n| MCP Tool Description Injection  | [#552644](https://gitlab.com/gitlab-org/gitlab/-/work_items/552644) |\n\nAI generated or assisted reports that include static code analysis without providing clear proof of exploitability and demonstrating practical security impact will not be accepted.\n\n## Out of scope\n- Automated scanning reports of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- TLS/SSL or SSH issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Denial of Service (DoS) issues\n    - **Note:** Exceptions may be considered for DoS vulnerabilities that both achieve persistent total service disruption AND can be executed through unauthenticated endpoints. The GitLab security team will determine, at our sole discretion, whether a report falls into this exception\n    - Volumetric attack (network flooding, request flooding, port flooding, etc.) submissions are never eligible\n    - A scenario where service disruption stops as soon as the requests stop does not qualify as persistent total service disruption, regardless of the request rate.\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- [Self-managed Runner](https://docs.gitlab.com/runner/security/) issues \n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md)\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers. Domains listed below are not eligible for vulnerability reports (GitLab reserves the right to adjust this list):\n  - `*.gitlab-private.org`\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- Metadata disclosure, enumeration, and information gathering issues are out of scope unless the researcher demonstrates a **privacy breach that exposes confidential user data or credentials**. GitLab is a collaborative DevOps platform designed for information sharing within projects.\n  - **Out of scope examples:**\n    - Enumerating project IDs or determining whether a project exists\n    - Accessing branch names, feature flag names, or version information visible to legitimate project members\n    - Discovering template names, default configuration settings, or non-sensitive project metadata (creation dates, public descriptions)\n    - Extracting version history metadata that does not expose confidential commit content\n  - **In scope examples (privacy breaches):**\n    - Revealing another user's private email address or credentials\n    - Accessing a different project's environment variables, secrets, or confidential CI/CD configuration you don't have legitimate access to\n    - Enumerating private repository contents without authorization\n    - Extracting confidential data from projects you don't have legitimate access to\n- DSN credentials for `new-sentry.gitlab.net`. As per  [sentry document](https://docs.sentry.io/concepts/key-terms/dsn-explainer/#the-parts-of-the-data-source-name-dsn):\n  \u003e 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.\n- Vulnerabilities that are only reproducible in our [GitLab Development kit](https://gitlab.com/gitlab-org/gitlab-development-kit). \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-05-05T23:19:18.285Z"},{"id":3772900,"new_policy":"# Rewards\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/install/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged. \n\n**We strongly encourage security testing on your local [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) instance** rather than GitLab.com for most vulnerability research. The GDK provides:\n- Access to the latest development features before public release\n- No rate limits or testing restrictions on your local instance\n- Safe environment for testing most vulnerability types\n- [GDK Security Testing Guide - link to create]\n\n**For Denial of Service (DoS) vulnerabilities specifically:** \nTesting 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](https://docs.gitlab.com/install/requirements/).\n**Never test DoS vulnerabilities on GitLab.com.**\n\nFor vulnerabilities requiring GitLab.com production architecture, you must use test accounts created with your HackerOne email alias (yourhandle@wearehackerone.com). **Never test against projects, groups, accounts, or instances you do not own.**\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe 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](https://docs.gitlab.com/user/duo_agent_platform/security_threats/). Stay tuned for further iterations to the Bug Bounty program around AI related vulnerabilites in the near future.\n\nBelow is a running table of known prompt injection vulnerabilities that are **out of scope** for the GitLab bug bounty program. Do not submit reports for these specific known instances.\n\n| Vulnerability  | Link |\n|---|---|\n| Duo Agentic Chat prompt injection vulnerability  | [#581264](https://gitlab.com/gitlab-org/gitlab/-/work_items/581264) |\n| Filename Injection in TRUSTED_INTERNAL Tools  | [#587934](https://gitlab.com/gitlab-org/gitlab/-/work_items/587934) |\n| Invisible Prompt Injection in Issues/MRs  | [#586481](https://gitlab.com/gitlab-org/gitlab/-/work_items/586481) |\n| Context Boundary Failure in GitLab Duo Agent Tools  | [#582995](https://gitlab.com/gitlab-org/gitlab/-/work_items/582995) |\n| TOCTOU and Prompt Injection in GitLab Duo \"Issue to MR\" Flow  | [#584107](https://gitlab.com/gitlab-org/gitlab/-/work_items/584107) |\n| Hidden Prompt Injection in AI Catalog Agents  | [#579778](https://gitlab.com/gitlab-org/gitlab/-/work_items/579778) |\n| MCP Tool Description Injection  | [#552644](https://gitlab.com/gitlab-org/gitlab/-/work_items/552644) |\n\nAI generated or assisted reports that include static code analysis without providing clear proof of exploitability and demonstrating practical security impact will not be accepted.\n\n## Out of scope\n- Automated scanning reports of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- TLS/SSL or SSH issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Denial of Service (DoS) issues\n    - **Note:** Exceptions may be considered for DoS vulnerabilities that both achieve persistent total service disruption AND can be executed through unauthenticated endpoints. The GitLab security team will determine, at our sole discretion, whether a report falls into this exception\n    - Volumetric attack (network flooding, request flooding, port flooding, etc.) submissions are never eligible\n    - A scenario where service disruption stops as soon as the requests stop does not qualify as persistent total service disruption, regardless of the request rate.\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- [Self-managed Runner](https://docs.gitlab.com/runner/security/) issues \n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md)\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers. Domains listed below are not eligible for vulnerability reports (GitLab reserves the right to adjust this list):\n  - `*.gitlab-private.org`\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- Metadata disclosure, enumeration, and information gathering issues are out of scope unless the researcher demonstrates a **privacy breach that exposes confidential user data or credentials**. GitLab is a collaborative DevOps platform designed for information sharing within projects.\n  - **Out of scope examples:**\n    - Enumerating project IDs or determining whether a project exists\n    - Accessing branch names, feature flag names, or version information visible to legitimate project members\n    - Discovering template names, default configuration settings, or non-sensitive project metadata (creation dates, public descriptions)\n    - Extracting version history metadata that does not expose confidential commit content\n  - **In scope examples (privacy breaches):**\n    - Revealing another user's private email address or credentials\n    - Accessing a different project's environment variables, secrets, or confidential CI/CD configuration you don't have legitimate access to\n    - Enumerating private repository contents without authorization\n    - Extracting confidential data from projects you don't have legitimate access to\n- DSN credentials for `new-sentry.gitlab.net`. As per  [sentry document](https://docs.sentry.io/concepts/key-terms/dsn-explainer/#the-parts-of-the-data-source-name-dsn):\n  \u003e 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.\n- Vulnerabilities that are only reproducible in our [GitLab Development kit](https://gitlab.com/gitlab-org/gitlab-development-kit). \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-04-20T22:58:28.004Z"},{"id":3770583,"new_policy":"# Rewards\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/install/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged. \n\n**We strongly encourage security testing on your local [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) instance** rather than GitLab.com for most vulnerability research. The GDK provides:\n- Access to the latest development features before public release\n- No rate limits or testing restrictions on your local instance\n- Safe environment for testing most vulnerability types\n- [GDK Security Testing Guide - link to create]\n\n**For Denial of Service (DoS) vulnerabilities specifically:** \nTesting 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](https://docs.gitlab.com/install/requirements/).\n**Never test DoS vulnerabilities on GitLab.com.**\n\nFor vulnerabilities requiring GitLab.com production architecture, you must use test accounts created with your HackerOne email alias (yourhandle@wearehackerone.com). **Never test against projects, groups, accounts, or instances you do not own.**\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe 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](https://docs.gitlab.com/user/duo_agent_platform/security_threats/). Stay tuned for further iterations to the Bug Bounty program around AI related vulnerabilites in the near future. \n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- TLS/SSL or SSH issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Denial of Service (DoS) issues\n    - **Note:** Exceptions may be considered for DoS vulnerabilities that both achieve persistent total service disruption AND can be executed through unauthenticated endpoints. The GitLab security team will determine, at our sole discretion, whether a report falls into this exception\n    -Volumetric attack (network flooding, request flooding, port flooding, etc.) submissions are never eligible\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- [Self-managed Runner](https://docs.gitlab.com/runner/security/) issues \n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md)\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers. Domains listed below are not eligible for vulnerability reports (GitLab reserves the right to adjust this list):\n  - `*.gitlab-private.org`\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- Metadata disclosure, enumeration, and information gathering issues are out of scope unless the researcher demonstrates a **privacy breach that exposes confidential user data or credentials**. GitLab is a collaborative DevOps platform designed for information sharing within projects.\n  - **Out of scope examples:**\n    - Enumerating project IDs or determining whether a project exists\n    - Accessing branch names, feature flag names, or version information visible to legitimate project members\n    - Discovering template names, default configuration settings, or non-sensitive project metadata (creation dates, public descriptions)\n    - Extracting version history metadata that does not expose confidential commit content\n  - **In scope examples (privacy breaches):**\n    - Revealing another user's private email address or credentials\n    - Accessing a different project's environment variables, secrets, or confidential CI/CD configuration you don't have legitimate access to\n    - Enumerating private repository contents without authorization\n    - Extracting confidential data from projects you don't have legitimate access to\n- DSN credentials for `new-sentry.gitlab.net`. As per  [sentry document](https://docs.sentry.io/concepts/key-terms/dsn-explainer/#the-parts-of-the-data-source-name-dsn):\n  \u003e 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.\n- Vulnerabilities that are only reproducible in our [GitLab Development kit](https://gitlab.com/gitlab-org/gitlab-development-kit). \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-04T18:31:11.622Z"},{"id":3770492,"new_policy":"# Rewards\n \n## Policy Version 2.0 (Effective: [DATE - 7 days from announcement])\n\n**Transition Notice for Researchers:** Reports submitted before 2026-01-22, 9:00pm Pacific Time (2026-01-23T00:05:00Z) will be evaluated under our previous policy version. Researchers with DOS related vulnerability research in progress as of 2026-01-15 have a 7-day grace period to submit reports to complete the research under previous policy terms. \n\n**Policy History:**\n- [Previous Policy Version (Archive Link)]\n- [Detailed Changelog \u0026 Announcement Blog Post]\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/install/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged. \n\n**We strongly encourage security testing on your local [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) instance** rather than GitLab.com for most vulnerability research. The GDK provides:\n- Access to the latest development features before public release\n- No rate limits or testing restrictions on your local instance\n- Safe environment for testing most vulnerability types\n- [GDK Security Testing Guide - link to create]\n\n**For Denial of Service (DoS) vulnerabilities specifically:** \nTesting 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](https://docs.gitlab.com/install/requirements/).\n**Never test DoS vulnerabilities on GitLab.com.**\n\nFor vulnerabilities requiring GitLab.com production architecture, you must use test accounts created with your HackerOne email alias (yourhandle@wearehackerone.com). **Never test against projects, groups, accounts, or instances you do not own.**\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe 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](https://docs.gitlab.com/user/duo_agent_platform/security_threats/). Stay tuned for further iterations to the Bug Bounty program around AI related vulnerabilites in the near future. \n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- TLS/SSL or SSH issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Denial of Service (DoS) issues\n    - **Note:** Exceptions may be considered for DoS vulnerabilities that both achieve persistent total service disruption AND can be executed through unauthenticated endpoints. The GitLab security team will determine, at our sole discretion, whether a report falls into this exception\n    -Volumetric attack (network flooding, request flooding, port flooding, etc.) submissions are never eligible\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- [Self-managed Runner](https://docs.gitlab.com/runner/security/) issues \n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md)\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers. Domains listed below are not eligible for vulnerability reports (GitLab reserves the right to adjust this list):\n  - `*.gitlab-private.org`\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- Metadata disclosure, enumeration, and information gathering issues are out of scope unless the researcher demonstrates a **privacy breach that exposes confidential user data or credentials**. GitLab is a collaborative DevOps platform designed for information sharing within projects.\n  - **Out of scope examples:**\n    - Enumerating project IDs or determining whether a project exists\n    - Accessing branch names, feature flag names, or version information visible to legitimate project members\n    - Discovering template names, default configuration settings, or non-sensitive project metadata (creation dates, public descriptions)\n    - Extracting version history metadata that does not expose confidential commit content\n  - **In scope examples (privacy breaches):**\n    - Revealing another user's private email address or credentials\n    - Accessing a different project's environment variables, secrets, or confidential CI/CD configuration you don't have legitimate access to\n    - Enumerating private repository contents without authorization\n    - Extracting confidential data from projects you don't have legitimate access to\n- DSN credentials for `new-sentry.gitlab.net`. As per  [sentry document](https://docs.sentry.io/concepts/key-terms/dsn-explainer/#the-parts-of-the-data-source-name-dsn):\n  \u003e 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.\n- Vulnerabilities that are only reproducible in our [GitLab Development kit](https://gitlab.com/gitlab-org/gitlab-development-kit). \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-03T15:21:05.858Z"},{"id":3768391,"new_policy":"# Rewards\n \n## Policy Version 2.0 (Effective: [DATE - 7 days from announcement])\n\n**Transition Notice for Researchers:** Reports submitted before 2026-01-22, 9:00pm Pacific Time (2026-01-23T00:05:00Z) will be evaluated under our previous policy version. Researchers with DOS related vulnerability research in progress as of 2026-01-15 have a 7-day grace period to submit reports to complete the research under previous policy terms. \n\n**Policy History:**\n- [Previous Policy Version (Archive Link)]\n- [Detailed Changelog \u0026 Announcement Blog Post]\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/install/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged. \n\n**We strongly encourage security testing on your local [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) instance** rather than GitLab.com for most vulnerability research. The GDK provides:\n- Access to the latest development features before public release\n- No rate limits or testing restrictions on your local instance\n- Safe environment for testing most vulnerability types\n- [GDK Security Testing Guide - link to create]\n\n**For Denial of Service (DoS) vulnerabilities specifically:** \nTesting 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](https://docs.gitlab.com/install/requirements/).\n**Never test DoS vulnerabilities on GitLab.com.**\n\nFor vulnerabilities requiring GitLab.com production architecture, you must use test accounts created with your HackerOne email alias (yourhandle@wearehackerone.com). **Never test against projects, groups, accounts, or instances you do not own.**\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe 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](https://docs.gitlab.com/user/duo_agent_platform/security_threats/). Stay tuned for further iterations to the Bug Bounty program around AI related vulnerabilites in the near future. \n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- TLS/SSL or SSH issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Denial of Service (DoS) issues\n    - **Note:** Exceptions may be considered for DoS vulnerabilities that both achieve persistent total service disruption AND can be executed through unauthenticated endpoints. The GitLab security team will determine, at our sole discretion, whether a report falls into this exception\n    -Volumetric attack (network flooding, request flooding, port flooding, etc.) submissions are never eligible\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- [Self-managed Runner](https://docs.gitlab.com/runner/security/) issues \n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md)\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers. Domains listed below are not eligible for vulnerability reports (GitLab reserves the right to adjust this list):\n  - `*.gitlab-private.org`\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- Metadata disclosure, enumeration, and information gathering issues are out of scope unless the researcher demonstrates a **privacy breach that exposes confidential user data or credentials**. GitLab is a collaborative DevOps platform designed for information sharing within projects.\n  - **Out of scope examples:**\n    - Enumerating project IDs or determining whether a project exists\n    - Accessing branch names, feature flag names, or version information visible to legitimate project members\n    - Discovering template names, default configuration settings, or non-sensitive project metadata (creation dates, public descriptions)\n    - Extracting version history metadata that does not expose confidential commit content\n  - **In scope examples (privacy breaches):**\n    - Revealing another user's private email address or credentials\n    - Accessing a different project's environment variables, secrets, or confidential CI/CD configuration you don't have legitimate access to\n    - Enumerating private repository contents without authorization\n    - Extracting confidential data from projects you don't have legitimate access to\n- DSN credentials for `new-sentry.gitlab.net`. As per  [sentry document](https://docs.sentry.io/concepts/key-terms/dsn-explainer/#the-parts-of-the-data-source-name-dsn):\n  \u003e 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.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-01-15T20:25:10.420Z"},{"id":3757041,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until further notice.\n- DoS vulnerabilities caused by unlimited input fields starting from 2025-04-03: (we are addressing these systematically through our [Input Field Size Limits Implementation](https://gitlab.com/groups/gitlab-org/-/epics/17317) initiative and will determine, at our sole discretion, whether a report falls into this category)\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers. Domains listed below are not eligible for vulnerability reports (GitLab reserves the right to adjust this list):\n  - `*.gitlab-private.org`\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n- DSN credentials for `new-sentry.gitlab.net`. As per  [sentry document](https://docs.sentry.io/concepts/key-terms/dsn-explainer/#the-parts-of-the-data-source-name-dsn):\n  \u003e 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.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-06-06T21:49:30.240Z"},{"id":3755032,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until further notice.\n- DoS vulnerabilities caused by unlimited input fields starting from 2025-04-03: (we are addressing these systematically through our [Input Field Size Limits Implementation](https://gitlab.com/groups/gitlab-org/-/epics/17317) initiative and will determine, at our sole discretion, whether a report falls into this category)\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers. Domains listed below are not eligible for vulnerability reports (GitLab reserves the right to adjust this list):\n  - `*.gitlab-private.org`\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-05-07T17:41:12.927Z"},{"id":3754707,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until further notice.\n- DoS vulnerabilities caused by unlimited input fields starting from 2025-04-03: (we are addressing these systematically through our [Input Field Size Limits Implementation](https://gitlab.com/groups/gitlab-org/-/epics/17317) initiative and will determine, at our sole discretion, whether a report falls into this category)\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-05-01T14:16:18.734Z"},{"id":3753443,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- DoS vulnerabilities caused by unlimited input fields starting from 2025-04-03: (we are addressing these systematically through our [Input Field Size Limits Implementation](https://gitlab.com/groups/gitlab-org/-/epics/17317) initiative and will determine, at our sole discretion, whether a report falls into this category)\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-04-09T13:38:40.425Z"},{"id":3753027,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- DoS vulnerabilities caused by unlimited input fields starting from 2024-04-03: (we are addressing these systematically through our [Input Field Size Limits Implementation](https://gitlab.com/groups/gitlab-org/-/epics/17317) initiative and will determine, at our sole discretion, whether a report falls into this category)\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-04-03T15:02:22.261Z"},{"id":3753014,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- DoS vulnerabilities caused by unlimited input fields starting from 2024-04-02: (we are addressing these systematically through our [Input Field Size Limits Implementation](https://gitlab.com/groups/gitlab-org/-/epics/17317) initiative and will determine, at our sole discretion, whether a report falls into this category)\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-04-03T13:27:49.960Z"},{"id":3747494,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-01-06T16:12:45.008Z"},{"id":3747395,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our [GitLab forest](https://tree-nation.com/trees/view/5119567) on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 [GitLab FOSS project](https://gitlab.com/gitlab-org/gitlab-foss) as well as the min [GitLab Project](https://gitlab.com/gitlab-org/gitlab). You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at [our jobs page](https://about.gitlab.com/jobs/).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-01-03T08:56:22.053Z"},{"id":3746406,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\n**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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-12-11T15:47:14.597Z"},{"id":3746325,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://handbook.gitlab.com/handbook/security/product-security/application-security/vulnerability-management/#vulnerability-vs-feature-vs-bug) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/product-security/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-12-10T11:23:09.993Z"},{"id":3745019,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\nCVSS 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-21T14:56:29.376Z"},{"id":3743701,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n- Attacks that require having a victim share or leak a privileged access token (e.g. personal access token, OAuth token, project or group access token, deploy token, `_gitlab_session` token, or runner authentication token). Reports about leaked team member access tokens are still in-scope and eligible for non-CVSS bounties.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-05T16:16:56.069Z"},{"id":3743697,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-05T15:48:56.454Z"},{"id":3743130,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning vulnerabilities in which an attacker can run pipeline jobs as an arbirtary user could be awarded up to $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-10-28T21:31:36.189Z"},{"id":3743129,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning vulnerabilities in which an attacker can run pipeline jobs as an arbirtary user could be awarded up to $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"SELF_SIGN_UP_CVSS_PR\",\"justification\":\"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\\\".\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-10-28T20:28:21.562Z"},{"id":3742322,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\nFor valid reports for which the author can't accept monetary rewards, we offer to plant trees in our (GitLab forest)[https://tree-nation.com/trees/view/5119567] on their behalf. \n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning vulnerabilities in which an attacker can run pipeline jobs as an arbirtary user could be awarded up to $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-10-17T15:34:34.288Z"},{"id":3741514,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning vulnerabilities in which an attacker can run pipeline jobs as an arbirtary user could be awarded up to $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n- Taking over third party domains, such as external sites linked in old blog posts, or claiming unused employee social media accounts.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-10-09T08:54:52.146Z"},{"id":3738083,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning vulnerabilities in which an attacker can run pipeline jobs as an arbirtary user could be awarded up to $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets, domains or subdomains that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-09-06T10:21:59.801Z"},{"id":3737710,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning vulnerabilities in which an attacker can run pipeline jobs as an arbirtary user could be awarded up to $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that do not provide access to GitLab company projects/groups/infrastructure or GitLab team member accounts (Please contact the owner of the token (you can find their email address by querying the `/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)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-09-03T14:41:36.541Z"},{"id":3734053,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning vulnerabilities in which an attacker can run pipeline jobs as an arbirtary user could be awarded up to $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-07-25T18:41:21.314Z"},{"id":3733980,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software.\n\nFor our fourth challenge, we are challenging you to impersonate users in CI pipelines. We're adding a bonus of $7,500 for a successful CI impersonation, meaning that an admin impersonation attack without user interaction will pay out $41,010!\n\n### Past Challenges: \n- 2023 Q3: Unauthenticated 0-click remote code execution \n- 2023 Q4: Account takeovers without any user interaction\n- 2024 Q1: Leak private data with AI features\n\n### Conditions\n\nThe normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts.\n\nReports must be submitted between July 24, 2024, 00:00:00 UTC and before October 23, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n\nIf the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time without prior notice and reason.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-07-25T14:53:30.106Z"},{"id":3730130,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos - unless our own automation missed it.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-06-19T13:05:29.880Z"},{"id":3725933,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n- CI/CD Variable Disclosure - as it stands, we currently see [our guidance to use external secret storage](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-security) as sufficient for addressing reports that rely on disclosing Masked or Protected CI/CD variables to prove impact. \n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-05-14T04:50:49.327Z"},{"id":3724727,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n- Server-side Denial of Service on *.gitlab.net assets.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-05-02T14:20:53.536Z"},{"id":3724721,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n- Takeover of S3 buckets that are used for testing or if the takeover don't have an impact on GitLab infrastructure or to GitLab customers.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-05-02T13:32:55.785Z"},{"id":3724116,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n### AI related vulnerabilities\nWe only accept issues related to the content of model prompts and responses if they have a directly verifiable security impact on GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-04-25T08:39:03.605Z"},{"id":3721691,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n- ReDoS issues from 2024-03-27, until GitLab [migrates](https://gitlab.com/groups/gitlab-org/-/epics/9684) to Ruby 3.2 and [global timeout](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145679) for Regexp is implemented.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-27T16:59:24.040Z"},{"id":3721465,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\nWe 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)](https://www.hackerone.com/policies/code-of-conduct) and might attract CoC enforcement actions.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-26T10:37:51.063Z"},{"id":3714578,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In the case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- In the case of reports related to Subdomain Takeovers, PoC's should create a simple page with your HackerOne handle as a single line of text at the affected URL. The page should utilize a UUID or complex string that wouldn't ordinarily be accessed. An example would be `vulnerable-subdomain.example.com/$UUID-poc.txt` where $UUID is a hard-to-guess value.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-14T15:05:25.422Z"},{"id":3713054,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our third challenge, we are challenging you to try to leak private data with our AI features. If you're able to leak contents of private projects (think code, issues etc) through any of the AI features, we'll add an extra $5,000 to the bounty!\n\n### Past Challenges:\n\n- 2023 Q3: Unauthenticated 0-click remote code execution\n- 2023 Q4: Account takeovers without any user interaction\n\n### Conditions\n- The normal GitLab Bug Bounty Program rules apply, such as only testing on your own accounts. Do not attempt to access private data of accounts you do not own.\n- Reports must be submitted before May 20, 2024, 00:00:00 UTC to be eligible for the challenge bonus\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-02-21T18:10:07.463Z"},{"id":3711301,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our second challenge, we're offering a reward for account takeovers without any user interaction. We will raise the bounty to $50,000 - regardless of the CVSS! \n\nWe have created a test account for your attacks, HackerOneGLQ4, with the UserId: 18975861. \n\n### Past Challenges: \n\n- 2023 Q3: the unauthenticated 0-click remote code execution\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2024-20-2 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against the test account specifed above, you may not exploit any other accounts than HackerOneGLQ4.\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-01-23T10:07:05.136Z"},{"id":3710075,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our second challenge, we're offering a reward for account takeovers without any user interaction. We will raise the bounty to $50,000 - regardless of the CVSS! \n\nWe have created a test account for your attacks, HackerOneGLQ4, with the UserId: 18975861. \n\n### Past Challenges: \n\n- 2023 Q3: the unauthenticated 0-click remote code execution\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2024-20-2 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against the test account specifed above, you may not exploit any other accounts than HackerOneGLQ4.\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n- `*.runway.gitlab.net` endpoints\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-01-02T12:35:28.138Z"},{"id":3708309,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our second challenge, we're offering a reward for account takeovers without any user interaction. We will raise the bounty to $50,000 - regardless of the CVSS! \n\nWe have created a test account for your attacks, HackerOneGLQ4, with the UserId: 18975861. \n\n### Past Challenges: \n\n- 2023 Q3: the unauthenticated 0-click remote code execution\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2024-20-2 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against the test account specifed above, you may not exploit any other accounts than HackerOneGLQ4.\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n- GitLab's ServiceNow platform.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-11-30T14:04:35.084Z"},{"id":3707976,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our second challenge, we're offering a reward for account takeovers without any user interaction. We will raise the bounty to $50,000 - regardless of the CVSS! \n\nWe have created a test account for your attacks, HackerOneGLQ4, with the UserId: 18975861. \n\n### Past Challenges: \n\n- 2023 Q3: the unauthenticated 0-click remote code execution\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2024-20-2 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against the test account specifed above, you may not exploit any other accounts than HackerOneGLQ4.\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user), [@joaxcar](https://hackerone.com/joaxcar?type=user), and [@0xn3va](https://hackerone.com/0xn3va?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2023/10/02/ask-a-hacker/) profiling [@0xn3va](https://hackerone.com/0xn3va?type=user), the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-11-24T09:41:50.548Z"},{"id":3707553,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our second challenge, we're offering a reward for account takeovers without any user interaction. We will raise the bounty to $50,000 - regardless of the CVSS! \n\nWe have created a test account for your attacks, HackerOneGLQ4, with the UserId: 18975861. \n\n### Past Challenges: \n\n- 2023 Q3: the unauthenticated 0-click remote code execution\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2024-20-2 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against the test account specifed above, you may not exploit any other accounts than HackerOneGLQ4.\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-11-23T21:04:25.802Z"},{"id":3707346,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. \n\nFor our second challenge, we're offering a reward for account takeovers without any user interaction. We will raise the bounty to $50,000 - regardless of the CVSS! \n\nWe have created a test account for your attacks, HackerOneGLQ4, with the UserId: 18975861. \n\n### Past Challenges: \n\n- 2023 Q3: the unauthenticated 0-click remote code execution\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2024-20-2 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against the test account specifed above, you may not exploit any other accounts than HackerOneGLQ4.\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-11-21T16:31:53.866Z"},{"id":3703927,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/runbooks/hackerone-process/). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/reproducible-vulnerabilities/) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-28T15:59:49.017Z"},{"id":3702149,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-14T09:01:37.265Z"},{"id":3702049,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos. Team member tokens, keys, and credentials leaked via public videos remain in scope.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-12T19:52:52.869Z"},{"id":3701619,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos.\n- Vulnerabilities in [Debian packages in the Package Registry](https://docs.gitlab.com/ee/user/packages/debian_repository/)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-06T05:49:29.079Z"},{"id":3700715,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n- Team member personal data leaked through YouTube videos (until October 31th 2023). We are currently working on 2 confidential issues ([here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/8) and [there](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/9)) that will be done by end of October 2023. After that date, we will resume accepting reports of team member personal data leaked via YouTube videos.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-31T09:57:20.697Z"},{"id":3699778,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\nPractices authorized under this GitLab HackerOne Bug Bounty Program policy are exceptions to GitLab's [Acceptable Use Policy](https://about.gitlab.com/handbook/legal/acceptable-use-policy/).\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-11T15:45:31.675Z"},{"id":3699663,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## The 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-08T22:59:24.968Z"},{"id":3699350,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n- Open redirects - in general these type of issues are informational and we only accept them if chained with other issues in order to create a more severe vulnerability\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-02T16:07:00.725Z"},{"id":3699347,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Dangling DNS records on gitlabsandbox.net \n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-02T15:58:49.720Z"},{"id":3699296,"new_policy":"# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## 90 Day Challenge\n\nEvery 90 days (give or take!), we'll be rolling out different incentives to boost research efforts into high-impact vulnerabilities and strengthen the security of our software. For our very first challenge, we're offering a reward for the holy grail of vulnerabilities: the unauthenticated 0-click remote code execution!\n\nIf you report a valid vulnerability with a CVSS score of 10.0 that allows an attacker to remotely execute arbitrary code on the GitLab server we'll raise your bounty to **$50,000**! This is a full $15,000 above our current maximum payout. We know that on GitLab.com you can easily create a user account, and sometimes there isn't much difference between `PR:L` and `PR:N`. However, the difference is major to our users running self-hosted GitLab instances without open registration – that's where `PR:N` makes a significant impact, and that's what we're after!\n\nLooking for inspiration? Have a look at [CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205).\n\n### Conditions\n\n- The normal GitLab Bug Bounty Program rules apply\n- Reports must be submitted before 2023-11-01 00:00:00 UTC to be eligible for the challenge bonus\n- Exploit the vulnerability against [your own installation](https://about.gitlab.com/install/) or using the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/), not against GitLab.com or any installation you do not own\n- This challenge is exclusively focused on server-side vulnerabilities. RCE in our client-side applications ([VS Code extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension/), [GLab](https://gitlab.com/gitlab-org/cli/), etc.) will be rewarded according to our standard bounty table\n- If the exploit is complicated to setup please include a script or a video demonstration to help triage your report\n\nGitLab reserves the right to stop this challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-01T17:03:53.197Z"},{"id":3699158,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n- Ability of banned users to behave as if they are unbanned. We have [a confidential epic](https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14) to improve this feature.\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-07-28T21:10:48.736Z"},{"id":3689313,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Demonstrating Impact\n\n- Always choose a non disruptive option to demonstrate the impact. If the only way to demonstrate an impact is a disruptive one then stop and report the issue, we will validate the impact.\n- In case of reports related to credential leaks do not create additional access credentials using the leaked one. We will determine impact ourselves and award for the maximum impact we uncover.\n- For sharing POC videos, directly upload the video in the report. Do not upload POC videos in public platforms until the report is disclosed.  Please refer to our disclosure policy for more details.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-14T07:27:00.269Z"},{"id":3687551,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\nPlease 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-05-11T20:04:39.431Z"},{"id":3683087,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\nPlease keep note of any IP addresses you use during your research, as this can help us when investigating and remediating vulnerabilities.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-02-07T07:25:03.871Z"},{"id":3681912,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Server-side Denial of Service on [customers.gitlab.com](https://customers.gitlab.com)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-01-11T14:43:29.293Z"},{"id":3681871,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Practice bug hunting with our [Reproducible Vulnerabilities](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html) resource.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-01-10T20:30:59.779Z"},{"id":3680406,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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, most HTML content injection, Tabnabbing\n- HTML or text injection is eligible only when significant impact can be achieved with minimal user interaction\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-11-29T01:26:06.909Z"},{"id":3680045,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\n\nThe [Gold Standard Safe Harbor](https://hackerone.com/gitlab/safe_harbor) applies.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-11-16T19:49:44.930Z"},{"id":3679694,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\nGitLab reserves the right to stop this capture the flag challenge and bonus at any time.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-11-08T23:27:12.259Z"},{"id":3679256,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nAt the moment there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our Bug Bounty Program with the steps to successfully reproduce. We will update this policy when the flag is found.To stay informed, subscribe to our program to receive policy updates and be notified when the flag has been claimed. At that time, our CTF will be paused, while we test and improve our defenses. Once we're ready we'll re-enable the flag and update our policy to indicate that the CTF is open again.\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n- Name squatting on dependencies without demonstrating automated impact (e.g. namesquatting a rubygem on rubygems.org where GitLab only ever installs a locally vendored gem)\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-10-31T21:39:38.614Z"},{"id":3677532,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nAt the moment there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our Bug Bounty Program with the steps to successfully reproduce. We will update this policy when the flag is found.To stay informed, subscribe to our program to receive policy updates and be notified when the flag has been claimed. At that time, our CTF will be paused, while we test and improve our defenses. Once we're ready we'll re-enable the flag and update our policy to indicate that the CTF is open again.\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n# Work at GitLab\n\nGitLab is regularly looking to hire talented security professionals. Learn more at https://about.gitlab.com/jobs/\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-09-21T20:22:36.646Z"},{"id":3677106,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nAt the moment there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our Bug Bounty Program with the steps to successfully reproduce. We will update this policy when the flag is found.To stay informed, subscribe to our program to receive policy updates and be notified when the flag has been claimed. At that time, our CTF will be paused, while we test and improve our defenses. Once we're ready we'll re-enable the flag and update our policy to indicate that the CTF is open again.\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please open an issue in [our HackerOne Questions GitLab project](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/)\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-09-07T22:54:20.491Z"},{"id":3676787,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project (project ID 38006449) which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nAt the moment there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our Bug Bounty Program with the steps to successfully reproduce. We will update this policy when the flag is found.To stay informed, subscribe to our program to receive policy updates and be notified when the flag has been claimed. At that time, our CTF will be paused, while we test and improve our defenses. Once we're ready we'll re-enable the flag and update our policy to indicate that the CTF is open again.\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-30T15:36:20.446Z"},{"id":3676542,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nAt the moment there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our Bug Bounty Program with the steps to successfully reproduce. We will update this policy when the flag is found.To stay informed, subscribe to our program to receive policy updates and be notified when the flag has been claimed. At that time, our CTF will be paused, while we test and improve our defenses. Once we're ready we'll re-enable the flag and update our policy to indicate that the CTF is open again.\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\nCheck out this blog post for some FAQs around this CTF: [Give it a go: Capture the flag for $20K USD in our bug bounty program](https://about.gitlab.com/blog/2022/08/24/capture-the-flag-in-our-bug-bounty-program/)\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and this [blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user), and [this blog](https://about.gitlab.com/blog/2022/07/27/cracking-our-bug-bounty-top-10/) where we chat with [@joaxcar](https://hackerone.com/joaxcar?type=user)\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-24T15:27:09.399Z"},{"id":3675486,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related vulnerability to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nAt the moment there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our Bug Bounty Program with the steps to successfully reproduce. We will update this policy when the flag is found.To stay informed, subscribe to our program to receive policy updates and be notified when the flag has been claimed. At that time, our CTF will be paused, while we test and improve our defenses. Once we're ready we'll re-enable the flag and update our policy to indicate that the CTF is open again.\n\nUse of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-01T15:07:45.075Z"},{"id":3675260,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## Capture the flag for $20,000\n\nWe recently [raised our bounty amounts](https://about.gitlab.com/blog/2021/11/01/3rd-annual-bug-bounty-contest/#increased-bounties-across-all-bounty-ranges) and finding a CVSS 10.0 vulnerability on GitLab will lead to, what we think, is a pretty good pay day. However, we've noticed that some vulnerabilities with very high business impacts don't receive as high of a CVSS score as a remote code execution vulnerability would because they \"only\" impact confidentiality. \n\nThis is why we're introducing a capture the flag contest!\n\n### How to get started in our CTF\n\nThe private group `gitlab-h1-bbp-ctf-group` (group ID 55842926) contains a private project which contains a file with a flag. The format of the flag is `{gitlab-bounty-flag-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}`. Use a permission-related issue to bypass access control; without user interaction, then read the flag and the $20,000 bonus is yours!\n\nAt the moment there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our Bug Bounty Program with the steps to successfully reproduce. We will update this policy when the flag is found.To stay informed, subscribe to our program to receive policy updates and be notified when the flag has been claimed. At that time, our CTF will be paused, while we test and improve our defenses. Once we're ready we'll re-enable the flag and update our policy to indicate that the CTF is open again.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-07-26T18:31:56.164Z"},{"id":3675083,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nWe 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.\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-07-21T16:20:29.749Z"},{"id":3673935,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) or additional rate limiting\n- Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-07-07T16:00:06.296Z"},{"id":3672404,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- Check out our Ask Me Anything (AMA) series with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user), [@vakzz](https://hackerone.com/vakzz?type=user) and [@joaxcar](https://hackerone.com/joaxcar?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-06-06T19:03:23.749Z"},{"id":3671770,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n- Bypassing or creating fake licenses, or bypasses of feature restrictions where there is no security impact\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We're hosting a live AMA with Johan Carlsson [@joaxcar](https://hackerone.com/joaxcar?type=user) on June 01, 2022 at 16:30 UTC. Sign up, join us and bring your questions: https://forms.gle/Vj8RgG7RAqPh6EMX6.\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our AMAs with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user) and [@vakzz](https://hackerone.com/vakzz?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-05-19T22:05:37.959Z"},{"id":3671760,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We're hosting a live AMA with Johan Carlsson [@joaxcar](https://hackerone.com/joaxcar?type=user) on June 01, 2022 at 16:30 UTC. Sign up, join us and bring your questions: https://forms.gle/Vj8RgG7RAqPh6EMX6.\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our AMAs with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user) and [@vakzz](https://hackerone.com/vakzz?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- See our Ask a Hacker blog series, where we profiled some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-05-19T19:53:35.600Z"},{"id":3668645,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n**Behave professionally**. Failure to follow HackerOne's policies, such as the [Code of Conduct](https://www.hackerone.com/policies/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.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our AMAs with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user) and [@vakzz](https://hackerone.com/vakzz?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-03-29T20:37:46.379Z"},{"id":3666660,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Access tokens that don't belong to GitLab projects/groups/team members (please contact the owner of the token, you can find their email address by querying the `/api/v4/user` API)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our AMAs with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user) and [@vakzz](https://hackerone.com/vakzz?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-02-16T22:27:20.738Z"},{"id":3664039,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier. The calculator we use to calculate CVSS-based bounty amounts is [accessible to everyone](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nReports 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.\n\nGitLab 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.\n\nWhile 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nUpon 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 \u0026 definitions\" section of our [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/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\".\n\nReports 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our AMAs with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user) and [@vakzz](https://hackerone.com/vakzz?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-01-07T20:36:06.790Z"},{"id":3658767,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nSee 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our AMAs with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user) and [@vakzz](https://hackerone.com/vakzz?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-09-22T23:02:32.628Z"},{"id":3653641,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our AMAs with [@rpadovani](https://hackerone.com/rpadovani?type=user), [@ajxchapman](https://hackerone.com/ajxchapman?type=user) and [@vakzz](https://hackerone.com/vakzz?type=user) in our [Live AMA playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s).\n- Want to see how Bug Bounty Hunters use GitLab to improve their research efforts? Check out [\"How do bug bounty hunters use GitLab to help their hack?\"](https://about.gitlab.com/blog/2021/06/11/how-i-use-gitlab-to-help-my-hack/). See all of our [bug bounty related blog posts](https://about.gitlab.com/blog/tags.html#bug-bounty).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-06-18T19:41:44.637Z"},{"id":3653234,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThis does _not_ include websites of third party software and services and only includes dependencies \u0026 packaged software.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our [Aug 25, 2020 AMA](https://www.youtube.com/watch?v=SK_vuZCafZ4\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s\u0026index=3) with [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [March 22, 2021 AMA](https://www.youtube.com/watch?v=Km6toD6CAAw\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s) with [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We have an AMA/Ask Me Anything with Hacker [@vakzz](https://hackerone.com/vakzz?type=user) happening on June 16 and the community is invited! Ask a question [sign up to join us](https://docs.google.com/forms/d/e/1FAIpQLSc4qcZCtQzci-heoBG30pZ730wviKxNJaL8sAIYVE9LsoNRCw/viewform)!\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-06-08T20:54:12.053Z"},{"id":3652663,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our [Aug 25, 2020 AMA](https://www.youtube.com/watch?v=SK_vuZCafZ4\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s\u0026index=3) with [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [March 22, 2021 AMA](https://www.youtube.com/watch?v=Km6toD6CAAw\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s) with [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We have an AMA/Ask Me Anything with Hacker [@vakzz](https://hackerone.com/vakzz?type=user) happening on June 16 and the community is invited! Ask a question [sign up to join us](https://docs.google.com/forms/d/e/1FAIpQLSc4qcZCtQzci-heoBG30pZ730wviKxNJaL8sAIYVE9LsoNRCw/viewform)!\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-24T15:02:25.305Z"},{"id":3652430,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n    - A response validating that a specific email address is registered\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our [Aug 25, 2020 AMA](https://www.youtube.com/watch?v=SK_vuZCafZ4\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s\u0026index=3) with [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [March 22, 2021 AMA](https://www.youtube.com/watch?v=Km6toD6CAAw\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s) with [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-18T20:14:56.555Z"},{"id":3652260,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on vulnerabilities in third-party software which GitLab depends on will be accepted and a bounty rewarded if and only if:\n* The report includes a new vulnerability, for which a patch is not available, or\n* A patch has been available for more than 30 days.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our [Aug 25, 2020 AMA](https://www.youtube.com/watch?v=SK_vuZCafZ4\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s\u0026index=3) with [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [March 22, 2021 AMA](https://www.youtube.com/watch?v=Km6toD6CAAw\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s) with [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-13T16:40:59.727Z"},{"id":3651061,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- We’ve recently kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the [blog](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) profiling [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [next blog](https://about.gitlab.com/blog/2021/03/04/ajxchapman-ask-a-hacker/) where we profile [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- We've also started a new, live Ask Me Anything (AMA) series. You can see our [Aug 25, 2020 AMA](https://www.youtube.com/watch?v=SK_vuZCafZ4\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s\u0026index=3) with [@rpadovani](https://hackerone.com/rpadovani?type=user) and the [March 22, 2021 AMA](https://www.youtube.com/watch?v=Km6toD6CAAw\u0026list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s) with [@ajxchapman](https://hackerone.com/ajxchapman?type=user).\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-04-12T19:28:25.959Z"},{"id":3650182,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab Inc. products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n  - This includes `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 `security@gitlab.cn`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- 🎉 Mark your calendar! **We'll be hosting a live AMA with [@ajxchapman](https://hackerone.com/ajxchapman?type=user) on March 22 at 15:30 UTC. Get all of the details [here](https://docs.google.com/forms/d/e/1FAIpQLSd_FFsK58KmUzYYIRU2P6BItjx1L9gnGrGY_RPz7_1pHTADAg/viewform?usp=sf_link) and submit a question!**\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA](https://youtu.be/SK_vuZCafZ4) with [@rpadovani](https://hackerone.com/rpadovani?type=user).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-22T17:37:51.673Z"},{"id":3650049,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- 🎉 Mark your calendar! **We'll be hosting a live AMA with [@ajxchapman](https://hackerone.com/ajxchapman?type=user) on March 22 at 15:30 UTC. Get all of the details [here](https://docs.google.com/forms/d/e/1FAIpQLSd_FFsK58KmUzYYIRU2P6BItjx1L9gnGrGY_RPz7_1pHTADAg/viewform?usp=sf_link) and submit a question!**\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA](https://youtu.be/SK_vuZCafZ4) with [@rpadovani](https://hackerone.com/rpadovani?type=user).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-18T19:04:32.249Z"},{"id":3649777,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- 🎉 Mark your calendar! **We'll be hosting a live AMA with [@ajxchapman](https://hackerone.com/ajxchapman?type=user) on March 22 at 16:30 UTC. Get all of the details [here](https://docs.google.com/forms/d/e/1FAIpQLSd_FFsK58KmUzYYIRU2P6BItjx1L9gnGrGY_RPz7_1pHTADAg/viewform?usp=sf_link) and submit a question!**\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA](https://youtu.be/SK_vuZCafZ4) with [@rpadovani](https://hackerone.com/rpadovani?type=user).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-09T18:49:46.459Z"},{"id":3648146,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- The [GitLab Red Team](https://about.gitlab.com/handbook/engineering/security/security-operations/red-team/) hosted a live, public AMA/Ask Me Anything on Jan. 26, 2021. Check out the [replay](https://youtu.be/FCu7MiRX5Lw).\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA](https://youtu.be/SK_vuZCafZ4) with [@rpadovani](https://hackerone.com/rpadovani?type=user).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-01-27T22:36:05.997Z"},{"id":3647976,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## GitLab Releases\n\nWe release new features on the 22nd of every month. You can [learn more about our release process](https://about.gitlab.com/releases/), see the latest [monthly release blog post](https://about.gitlab.com/releases/categories/releases/) and see what's coming in [future releases](https://about.gitlab.com/upcoming-releases/). If you're bug hunting, might we suggest a newly released feature? 😉\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- The GitLab Red Team is hosting a live AMA/Ask Me Anything event on Jan. 26, 2021 at 21:30 UTC. This event is open to the wider community. [Join us!](https://docs.google.com/forms/d/e/1FAIpQLSekc1LYWYbhORNzZvLza8Btn9V0wY7K9SGVZed5RpJbczqdfw/viewform?usp=sf_link)\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA](https://youtu.be/SK_vuZCafZ4) with [@rpadovani](https://hackerone.com/rpadovani?type=user).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-01-22T18:29:39.418Z"},{"id":3647928,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/) and web assets. 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.\n\n# Rewards\n\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n| Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9) | Critical (9.0 - 10.0) |\n| --------------- | ------------------ | ---------------- | --------------------- |\n| $50 - $500      | $500 - $1,500      | $3,000 - $10,000 | $10,000 - $20,000     |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n## How severity is determined\n\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users and data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n\n## Duplicates\n\nFor 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.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# SLA\n\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* Time to triage (from report submit) - 5 business days\n* Time to bounty (from triage) - between 5 and 45 business days\n\nThe 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.\n\n# Scope\n\nAll GitLab products are in scope unless explicitly noted otherwise.\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n## Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer, including employee computer compromise\n- Man-in-the-middle attacks\n- 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\n- Missing Security Headers (eg. HSTS, CSP) and Missing Secure Flags on Cookies\n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Disclosure\n\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- The GitLab Red Team is hosting a live AMA/Ask Me Anything event on Jan. 26, 2021 at 21:30 UTC. This event is open to the wider community. [Join us!](https://docs.google.com/forms/d/e/1FAIpQLSekc1LYWYbhORNzZvLza8Btn9V0wY7K9SGVZed5RpJbczqdfw/viewform?usp=sf_link)\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA](https://youtu.be/SK_vuZCafZ4) with [@rpadovani](https://hackerone.com/rpadovani?type=user).\n- If you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-01-21T19:40:48.840Z"},{"id":3647861,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- The GitLab Red Team is hosting a live AMA/Ask Me Anything event on Jan. 26, 2021 at 21:30 UTC. This event is open to the wider community. [Join us!](https://docs.google.com/forms/d/e/1FAIpQLSekc1LYWYbhORNzZvLza8Btn9V0wY7K9SGVZed5RpJbczqdfw/viewform?usp=sf_link)\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA](https://youtu.be/SK_vuZCafZ4) with [@rpadovani](https://hackerone.com/rpadovani?type=user).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-01-20T00:00:43.700Z"},{"id":3647859,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Additional Information of Interest\n\n- For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n- The GitLab Red Team is hosting a live AMA/Ask Me Anything event on Jan. 26, 2021 at 21:30 UTC. This event is open to the wider community. [Join us!](https://docs.google.com/forms/d/e/1FAIpQLSekc1LYWYbhORNzZvLza8Btn9V0wY7K9SGVZed5RpJbczqdfw/viewform?usp=sf_link)\n- We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA with [@rpadovani](https://hackerone.com/rpadovani?type=user)](https://youtu.be/SK_vuZCafZ4).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-01-19T23:51:10.307Z"},{"id":3647858,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Additional Information of Interest\n\n* For more details on the process the GitLab Security Team follows when working with HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process). This includes further details on our triage and award review process.\n\n* The GitLab Red Team is hosting a live AMA/Ask Me Anything event on Jan. 26, 2021 at 21:30 UTC. This event is open to the wider community. [Join us!](https://docs.google.com/forms/d/e/1FAIpQLSekc1LYWYbhORNzZvLza8Btn9V0wY7K9SGVZed5RpJbczqdfw/viewform?usp=sf_link)\n\n* We’ve also kicked off a Ask a Hacker blog series, where we profile some of our top hackers. See the first blog [here](https://about.gitlab.com/blog/2020/11/10/rpadovani-ask-a-hacker/) and the [accompanying AMA with [@rpadovani](https://hackerone.com/rpadovani?type=user)](https://youtu.be/SK_vuZCafZ4).\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-01-19T23:42:18.360Z"},{"id":3644475,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess will not be accepted. Examples include but are not limited to:\n    - An API route returning different status codes depending on if a private path exists or not\n    - An identical response but with significantly different timing depending on if a private path exists or not\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-10-28T03:38:00.483Z"},{"id":3643437,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\nGitLab 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-10-07T16:00:50.797Z"},{"id":3643224,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Our customers' GitLab installs\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-10-05T19:26:54.152Z"},{"id":3643043,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Gitter ([no longer owned by GitLab](https://blog.gitter.im/2020/09/30/gitter-element-acquisition/))\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-30T16:56:19.360Z"},{"id":3642722,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (we are aware of the lack of rate-limiting in many places and our application-wide [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits) initiative aims to improve that)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-22T19:05:18.152Z"},{"id":3641984,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n- EXIF metadata not being stripped from images\n  - We are aware of ways to bypass the EXIF metadata stripping and intend to improve this, but we don't consider this impactful enough to be eligible for bounty\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-03T00:03:09.194Z"},{"id":3641929,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n- Issues affecting only Internet Explorer as it is not a [supported web browser](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)\n  - Note that Microsoft Edge is supported\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-02T01:15:36.235Z"},{"id":3640653,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n- Being able to access attachments directly with a known URL (this is a [documented behavior](https://gitlab.com/help/security/user_file_uploads.md) and we have an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) discussing ways to improve this)\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-07-29T16:39:14.110Z"},{"id":3639804,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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](https://www.hackerone.com/blog/reputation-signal-impact-enhancements-whats-changing-and-why-it-matters) 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - `docs.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `partners.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n    - `beta.gitter.im`\n    - `blog.gitter.im`\n    - `files.gitter.im`\n    - `next.gitter.im`\n    - `update.gitter.im`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-07-20T18:01:22.974Z"},{"id":3639647,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n## Zero-day vulnerabilities in 3rd-party dependencies \u0026 packaged software\n\nReports on zero-day vulnerabilities in third-party software which GitLab depends on will be accepted and a **reduced** bounty rewarded if and only if:\n* It is a third-pary zero-day, defined as there's either no patch for the vulnerability or a patch has been released and it's 30 days or more of age.\n* It has a clear and working proof of concept that illustrates the impact to GitLab.\n* It has Critical or High impact to GitLab.\n\nThe reduced bounty will be a maximum of fifty percent of our regular payout table.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - `docs.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `partners.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n    - `beta.gitter.im`\n    - `blog.gitter.im`\n    - `files.gitter.im`\n    - `next.gitter.im`\n    - `update.gitter.im`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-07-15T21:25:03.556Z"},{"id":3638791,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* Time to bounty (from triage) - between 5 and 45 business days. A bounty is awarded at the lastest after a patch has been released, which depends on the severity of a finding.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $50 - $500 | $500 - $1,500 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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 when the report is resolved or 45 days after triage, whichever happens earlier.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - `docs.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `partners.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n    - `beta.gitter.im`\n    - `blog.gitter.im`\n    - `files.gitter.im`\n    - `next.gitter.im`\n    - `update.gitter.im`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-06-30T19:00:22.687Z"},{"id":3638400,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur rewards are based on impact to our users, defined below. Please note these are general guidelines, and that reward decisions are up to the discretion of GitLab.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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 by considering multiple factors including but not limited to:\n\n* The quantity of affected users\n* The quantity of affected data\n* The sensitivity and classification of the affected data, and the security requirements surrounding it\n* The impact to the affected data's confidentiality, integrity, or availability\n* The privilege level required to exploit\n* A working and reproducible proof of concept\n* The difficulty to exploit\n* Whether it requires user interaction\n* Other, if any, mitigating factors or exploit scenario requirements\n\nWhile 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.\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - `docs.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `partners.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n    - `beta.gitter.im`\n    - `blog.gitter.im`\n    - `files.gitter.im`\n    - `next.gitter.im`\n    - `update.gitter.im`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-06-24T17:32:36.428Z"},{"id":3638266,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - `docs.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `partners.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n    - `beta.gitter.im`\n    - `blog.gitter.im`\n    - `files.gitter.im`\n    - `next.gitter.im`\n    - `update.gitter.im`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-06-22T15:51:19.468Z"},{"id":3637591,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - `docs.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n    - `beta.gitter.im`\n    - `blog.gitter.im`\n    - `files.gitter.im`\n    - `next.gitter.im`\n    - `update.gitter.im`\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-06-19T19:04:15.203Z"},{"id":3637422,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n## Testing on GitLab.com\nWhen 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](https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases). 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.\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-06-16T21:11:24.601Z"},{"id":3637183,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n- Clickjacking on pages with no sensitive actions\n- 500 errors or any other error that affects only the attacking request (please see the `Rules of Engagement, Testing, and Proof-of-concepts` for the rules concerning testing for Denial of Service (DoS) and other potentially disruptive activities)\n- High privilege users (maintainers, owners) using a bug to sabotage/deface their own projects\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-06-09T18:43:23.801Z"},{"id":3636240,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example our marketing issues at https://gitlab.com/gitlab-com/marketing\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-05-14T20:01:25.189Z"},{"id":3636225,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- GitLab Visual Studio Code Extension\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-05-14T16:18:04.969Z"},{"id":3635819,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n- Spoofing email and username in git commits that aren't [signed with GPG](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-05-04T16:49:25.694Z"},{"id":3635424,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-04-24T21:54:43.018Z"},{"id":3633931,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Client side Denial Of Service that is caused by browser bugs\n  - SVG rendering bugs are an example of this and the browsers are tracking these issues (see [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=617891) and [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=455100) bugtrackers for example)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-03-25T18:11:54.296Z"},{"id":3631805,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-28T15:19:11.761Z"},{"id":3631637,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n## GitLab Ultimate License\n\nReporters 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, links to your other two valid reports, and your email address to receive the license. Any further valid submissions in that year will extend you the next year's license for free too.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-26T17:52:39.269Z"},{"id":3630844,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nThe 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-18T17:51:29.503Z"},{"id":3630008,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n|  Low (0.1 - 3.9) | Medium (4.0 - 6.9) | High (7.0 - 8.9)  | Critical (9.0 - 10.0) |\n|----------|--------|---------|------|\n| $100 - $1,000 | $1,000 - $3,000 | $3,000 - $10,000 | $10,000 - $20,000 |\n\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-06T19:51:41.503Z"},{"id":3629837,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.)\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n- Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects\n  - For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted\n  - However being able to demonstrate that there are 4 confidential issues with the word \"SECRET TOKEN\" in them would be a valid report\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-04T22:18:55.301Z"},{"id":3627065,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n- GitLab Runner reports that do not demonstrate the ability to impact data of other projects or GitLab infrastructure\n  - Note that it is [documented behavior](https://docs.gitlab.com/runner/executors/shell.html#security) of the Shell Executor to be able to see other projects on the same server\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-30T14:42:08.552Z"},{"id":3626988,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n  - Reports where an attacker can validate a guess (for example an API route returning different status codes depending on if a private path exists or not) will not be accepted\n  - Reports where an attacker can only disclose the ID of a private element will not be accepted\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-28T00:51:09.854Z"},{"id":3625882,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n- Bypassing our [media assest proxy](https://docs.gitlab.com/ee/security/asset_proxy.html) for loading media files\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-11T19:22:50.621Z"},{"id":3625673,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-foss and https://gitlab.com/gitlab-org/gitlab. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-09T19:39:25.035Z"},{"id":3625671,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n- Client side Denial Of Service that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Server side Denial Of Service with a temporary impact on performance that can be solved by tuning [application limits](https://gitlab.com/groups/gitlab-org/-/epics/1737#type-of-limits)\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n`Informative` or self-closed reports that are determined to be bugs or new [feature requests](https://about.gitlab.com/handbook/engineering/security/#feature) with no current security impact may be imported as public issues in our issue tracker at https://gitlab.com/gitlab-org/gitlab/issues.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-09T19:33:30.541Z"},{"id":3625670,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Subdomain takeovers\n- Other things that would obviously leave customer data vulnerable\n \nTesting 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 [allow reporters to self-close](https://about.gitlab.com/handbook/engineering/security/#closing-reports-as-informative-not-applicable-or-spam) reports that are not applicable 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.\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-09T19:28:12.367Z"},{"id":3624558,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Other things that would obviously leave customer data vulnerable\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - `aptly.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/path disclosure unless an additional impact can be demonstrated\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\n\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n\n# Our Process and Further Information\n\nFor more details on the process the GitLab Security Team follows when working\nwith HackerOne reports, please see [our handbook](https://about.gitlab.com/handbook/engineering/security/#hackerone-process).\nThis includes further details on our triage and award review process.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-25T19:00:59.996Z"},{"id":3624274,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Other things that would obviously leave customer data vulnerable\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User and project enumeration/disclosure unless an additional impact can be demonstrated\n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-21T21:49:44.808Z"},{"id":3623916,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Other things that would obviously leave customer data vulnerable\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $20,000  | $10,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-18T17:38:14.109Z"},{"id":3621480,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Other things that would obviously leave customer data vulnerable\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# Disclosure\nAll `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](https://docs.hackerone.com/programs/disclosure.html#requesting-disclosure).\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-10-17T16:24:37.328Z"},{"id":3620866,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Other things that would obviously leave customer data vulnerable\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nFor 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.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-10-09T17:32:48.661Z"},{"id":3619869,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Other things that would obviously leave customer data vulnerable\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n    - Tabnabbing\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-09-24T19:35:28.910Z"},{"id":3611668,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services\n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com\n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Session Management\n- Other things that would obviously leave customer data vulnerable\n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.\n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.).\n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n- Side-channel timing attacks\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor\nAny 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.\n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-06-11T12:28:42.335Z"},{"id":3608454,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Session Management\n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - internationalized domain name (IDN) homograph attacks\n    - Right-to-left (RTL) Ambiguity, RTL Override (RTLO)\n    - SPF and DKIM issues\n    - HTML content injection\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-04-29T08:36:39.592Z"},{"id":3606266,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Session Management\n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\nReports 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.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering, phishing, or other fraud including but not limited to:\n    - IDN homograph attacks\n    - RTL Ambiguity\n    - SPF and DKIM issues\n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n- Text injection is eligible only on sensitive pages (for example, settings or authentication pages)\n- Reports about CVEs published on mailing lists, groups etc. without demonstrating an impact on GitLab\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-03-27T09:46:48.896Z"},{"id":3602693,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Session Management\n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Attacks requiring physical access to the victim's computer\n- Man-in-the-middle attacks\n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-02-13T17:20:01.730Z"},{"id":3601735,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Physical attacks \n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n\n# Eligibility for Participation\n\nYou 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.\n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-01-31T10:23:47.945Z"},{"id":3600643,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\nPlease refrain from submitting your report or inquiring about its status through additional channels, as this unnecessarily binds resources in the security team.\n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Physical attacks \n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n\n# Feedback\nIf you have suggestions for improving this program, please let us know at \u003csecurity@gitlab.com\u003e.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-01-16T19:30:34.709Z"},{"id":3600216,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com. \n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 1 business day\n* 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.\n* 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.\n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Physical attacks \n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-01-11T11:35:49.326Z"},{"id":3597833,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com. \n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days or less\n* Time to triage (from report submit) - 10 business days or less\n* Time to bounty (from triage) - 10 business days \n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts many customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Physical attacks \n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-12-12T18:15:57.099Z"},{"id":3597703,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com. \n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days or less\n* Time to triage (from report submit) - 10 business days or less\n* Time to bounty (from triage) - 10 business days \n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts multiple customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\n - Generating abuse requests\n - Submission of support, sales or other requests to 3rd party systems\n - Mass creation of users, groups, and projects\n - Typosquatting or other namesquatting\n - Spam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Physical attacks \n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-12-11T22:16:13.015Z"},{"id":3597573,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com. \n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days or less\n* Time to triage (from report submit) - 10 business days or less\n* Time to bounty (from triage) - 10 business days \n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n    - https://gitlab.com\n    - https://registry.gitlab.com\n    - https://customers.gitlab.com \n    - https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts multiple customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\nGenerating abuse requests\nSubmission of support, sales or other requests to 3rd party systems\nMass creation of users, groups, and projects\nTyposquatting or other namesquatting\nSpam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Physical attacks \n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-12-10T19:54:04.496Z"},{"id":3597572,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com. \n\n# SLA\nGitLab will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days or less\n* Time to triage (from report submit) - 10 business days or less\n* Time to bounty (from triage) - 10 business days \n\n# In scope \n- Your own GitLab [installation](https://about.gitlab.com/installation/).\n- GitLab.com production services \n- https://gitlab.com\n- https://registry.gitlab.com\n- https://customers.gitlab.com \n- https://gitter.im\n- GitLab products, including SaaS offering\n- SQL injection \n- Remote code execution \n- Cross-site scripting \n- Cross-site request forgery \n- Directory Traversal \n- Information Disclosure \n- Privilege escalation \n- Other things that would obviously leave customer data vulnerable \n\n# Rewards\nOur 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.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $12,000  | $7,000 | $3000    | $1000 |\n\nThe 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 $7000, etc.\n\n# How severity is determined\nGitLab 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts multiple customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Rules of Engagement, Testing, and Proof-of-concepts\n\nWhen 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:\nGenerating abuse requests\nSubmission of support, sales or other requests to 3rd party systems\nMass creation of users, groups, and projects\nTyposquatting or other namesquatting\nSpam-like or other high volume activity\n\nSending reports from automated tools without verifying them will immediately disqualify the report.  \n\nDisruptive 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 at https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee. You are encouraged to [install](https://about.gitlab.com/installation/) your own standalone instance for researching vulnerabilities. Screen captures, logs, and videos showing vulnerabilities against your own GitLab installation are encouraged.\n\n# Out of scope \n- Automated scanning of any kind \n- GitLab sites of third party software and services (marketing services, third-party mail services, developer/support installations etc.). \n- Subdomains on gitlab.com that are out of scope are:\n    - `shop.gitlab.com`\n    - `forum.gitlab.com`\n    - `support.gitlab.com`\n    - `alerts.gitlab.com`\n    - `status.gitlab.com`\n    - [Static website](https://about.gitlab.com) at `about.gitlab.com`\n    - [Public Information](https://dashboards.gitlab.com) at `dashboards.gitlab.com`\n    - `*.gitlab.net`\n    - `*.gitlap.com` (Note the letter `p` at the end of `gitlap`)\n- User content on GitLab.com (for example, a user that is not using proper permissions on their projects containing sensitive information)\n- Self-hosted installs of GitLab CE and GitLab EE customers\n- Intentionally public information and hosts, for example, https://dashboards.gitlab.com\n- Physical attacks \n- Social engineering \n- Employee computer compromise \n- Missing Security Headers (eg. HSTS, CSP) \n- Missing Secure Flags on Cookies \n- SSL or ssh issues (weak ciphers/key-size/BEAST/CRIME) \n- CSRF without any security impact \n- User Enumeration \n- Rate Limiting (unless it constitutes a significant risk)\n\n# Reports of broken links \nWe 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. \n\n# THANKS \nWe 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](https://hackerone.com/gitlab/thanks).\n\n# Duplicates\nFor 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.\n\n# Safe Harbor \nAny 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. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-12-10T19:53:13.619Z"},{"id":3577662,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, developer installations, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n- Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV.\n\n# How severity is determined\nGitLab reserves the right to make a final decision regarding severity of a reported finding. Upon receipt of the finding, we will conduct an internal investigation and determine the severity of the finding.  In many cases we may adjust the severity lower or higher depending on the percentage of affected users.\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts multiple customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-05-24T19:39:04.737Z"},{"id":3575418,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, developer installations, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n- Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV.\n\n# How severity is determined\nGitLab reserves the right to make a final decision regarding 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:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts multiple customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-05-03T17:38:50.415Z"},{"id":3575417,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, developer installations, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n- Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV.\n\n# How severity is determined\nGitLab reserves the right to make a final decision regarding severity of a reported finding. Upon receipt of the finding, we will conduct an internal investigations and determine the severity of the finding according to the following guidelines:\n\n- Critical (9.0-10.0) - the finding impacts \u003e 50% of our customer base.\n- High (7.0-8.0) - the finding impacts multiple customers in our customer base.\n- Medium (4.0 - 6.9) - the finding impacts few customers in our customer base.\n- Low (0.1 - 3.9) - the finding impacts no customers in our customer base.\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-05-03T17:35:04.044Z"},{"id":3575350,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, developer installations, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n- Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV.\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-05-02T16:07:05.691Z"},{"id":3560295,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n- Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV.\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# Reports of broken links\nWe 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.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-09-11T22:51:18.304Z"},{"id":3560197,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n- Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV.\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# Reports of broken links\nWe 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\".\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-09-08T16:34:35.111Z"},{"id":3557952,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n- Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV.\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-07-20T05:28:29.400Z"},{"id":3541530,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- GitLab.com production services (https://*.gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties (marketing services, third-party mail services, etc.)\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n\n# Testing and Proof-of-Concept\nPlease do not conduct testing against GitLab production services and do not use these services\nto develop Proof-of-Concept code for submitting reports. Screen captures, logs, and videos \nshowing vulnerabilities against your own GitLab installation are encouraged.\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-11-08T18:26:20.212Z"},{"id":2262596,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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. If you'd like to get additional attention to a report or feel we can improve with report handling please let us know at security@gitlab.com.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- [GitLab.com production service](https://gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties.\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-02-17T17:57:01.037Z"},{"id":2229642,"new_policy":"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](https://gitlab.com/gitlab-org/gitlab-ce/tree/master). 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.\n\n# In scope\n- Your own GitLab [installation](https://about.gitlab.com/installation/)\n- SQL injection\n- Remote code execution\n- Cross-site scripting\n- Cross-site request forgery\n- Directory Traversal\n- Information Disclosure\n- Privilege escalation\n- Other things that would obviously leave customer data vulnerable\n\n# Out of scope\n- Automated scanning of any kind\n- [GitLab.com production service](https://gitlab.com)\n- [Static website](https://about.gitlab.com)\n- GitLab sites of third parties.\n- Physical attacks\n- Social engineering\n- Employee computer compromise\n- Missing Security Headers (eg. HSTS, CSP)\n- Missing Secure Flags on Cookies\n- SSL issues (weak ciphers/key-size/BEAST/CRIME)\n- CSRF without any security impact\n- User Enumeration\n- Rate Limiting (unless it constitutes a significant risk)\n- Email sending checks\n\n# THANKS\nWe 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](https://hackerone.com/gitlab/thanks).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-02-06T01:31:16.099Z"}]