Source-driven security research into the authorization architecture of GitLab, conducted against the public GitLab bug bounty program on HackerOne under its published scope and Gold-Standard Safe-Harbor terms.
This repository documents a research process, not a trophy case. It records how candidate vulnerabilities were hypothesized from recently shipped source code, investigated against GitLab's actual implementation, and then either eliminated with evidence or escalated for responsible disclosure. The value it is meant to demonstrate is methodological: disciplined authorization analysis of a large unfamiliar codebase, honest handling of evidence, and responsible-disclosure ethics.
All testing is source-code review and analysis. No production GitLab system was attacked. No user data was accessed. Reproduction of any candidate finding is designed to happen only on a self-hosted instance the researcher owns, exactly as the program's rules require.
This is early-stage research, and the numbers below are stated without inflation.
| Metric | Value |
|---|---|
| Vulnerabilities submitted to GitLab | None yet |
| CVEs claimed | None |
| Bounties claimed | None |
| Hypotheses investigated and eliminated with source evidence | 21 |
| Findings pending disclosure to the vendor | 1 — details withheld |
One authorization finding from this research is being prepared for submission to the vendor's
security program. It has not been submitted yet. Its affected subsystem, mechanism, code locations,
and reproduction are deliberately withheld from this public repository until it is reported and
fixed. See
docs/05-active-research.md for the process that produced it and how
it is being handled.
Nothing in this repository asserts a confirmed vulnerability, a payment, or professional credentials that do not exist. Where a claim is uncertain or unverified, it is labeled as such.
- Reading and reasoning about a large, unfamiliar codebase. GitLab is a multi-million-line Ruby on Rails / GraphQL / Grape application. The work here navigates its authorization model — policies, GraphQL type/field authorization, granular access tokens, declarative roles, and markdown reference redaction — and reasons about where a check could be missing.
- Forming and falsifying security hypotheses. Each of the 21 eliminated leads is a concrete, falsifiable hypothesis ("this new type suppresses type-level authorization and exposes X"), traced through the code to a verdict. Most were rejected — and the reasoning for each rejection is recorded so the dead end is never walked twice.
- Understanding a real bug-bounty program's economics and rules. The research is grounded in what GitLab actually pays for (an analysis of 400 publicly disclosed reports), in the program's scope boundaries, and in its duplicate rule (which judges by fix, not attack vector).
- Responsible-disclosure discipline. The one candidate finding is being handled correctly: reproduce privately first, report to the vendor, publish only after it is fixed and disclosed.
This research was conducted under a strict set of self-imposed rules, aligned with the GitLab program policy:
- Authorized targets only. Testing is confined to what a program's published scope permits. Out-of-scope targets are off limits regardless of how easy they look.
- No production testing. No action was taken that could degrade a live service or touch real user data. All reproduction is designed for a self-hosted instance the researcher controls.
- No automated attack tooling against the target, and no automated report submission — reports are drafted for human review and submitted manually.
- Responsible disclosure. A live, unfixed vulnerability is never published before the vendor has had the opportunity to fix it. This is why the active candidate is redacted here.
- No fabrication. Verified findings, hypotheses, and eliminated leads are clearly distinguished. Publicly disclosed third-party reports are cited as evidence of bug classes, never presented as the researcher's own work.
Start with the methodology, then read the eliminated hypotheses — that is where the substance is.
| Document | What it contains |
|---|---|
docs/01-methodology.md |
The research process end to end: target selection, lead generation from freshly shipped code, the qualification filter, and the reproduce-and-report workflow. |
docs/02-architecture-analysis.md |
Analysis of GitLab's authorization architecture — the mechanisms a hunter must understand to find (or rule out) an access-control bug. |
docs/03-attack-patterns-and-intelligence.md |
Four recurring bug patterns derived from disclosed reports, plus a CWE breakdown of 400 publicly disclosed GitLab reports. |
docs/04-eliminated-hypotheses.md |
The core: all 21 hypotheses, each with the claim, how it was investigated, and why it was rejected. |
docs/05-active-research.md |
The one finding pending disclosure — process only, no technical details. |
docs/06-lessons-learned.md |
What this research taught about hunting a mature, well-defended program. |
Throughout, claims carry one of these labels, borrowed from the working notes:
- [verified] — read directly in the source, or confirmed against a primary source.
- [inferred] — reasoned from the code, but not executed.
- [unverified] — plausible but not yet confirmed; treat with caution.
Source references point at GitLab's open-source tree
(gitlab-org/gitlab, community edition mirror at gitlabhq/gitlabhq), read at v19.4.0-pre
around 2026-08-30. GitLab's source is public, so file and line references cite public code.
This is not a disclosure of any unfixed vulnerability, not a set of exploit payloads, and not instructions for attacking any GitLab system. It is a record of research method and reasoning. If you are looking to report a GitLab security issue, use the official program.