# Stored-XSS with CSP-bypass via labels' color

GitLab GitHub importer failed to sanitize label colors, letting a malicious GitHub host inject stored XSS that bypassed CSP on the labels page.

- Payout: hidden
- Severity: high
- Program: GitLab
- Found by: yvvdwf
- Disclosed: 2023-02-19
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/1665658
- Library page: https://bugbountylibrary.com/r/h1%3A1665658
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:high tech:rest technique:recon vuln:misconfiguration vuln:xss

**Target:** GitHub project importer / labels page
**Root cause:** The GitHub import feature copied label color values into GitLab without sanitization, so a crafted color string was rendered into the labels page HTML/CSS context.
**Steps:**
1. Host a dummy GitHub server (node index.js IP PORT) returning a repo whose label color contains an XSS payload.
2. Create a GitLab personal access token with api scope.
3. POST to `https://gitlab.com/api/v4/import/github` with `github_hostname` pointing at the dummy server, a fake `personal_access_token`, `repo_id`, and `target_namespace`.
4. Open the imported project's `/-/labels` page; the injected `alert(document.domain)` fires, bypassing CSP.
**How found:** Noticed the GitHub importer copies label colors verbatim and that GitHub normally restricts color format, so they built a dummy GitHub server to supply arbitrary color values and test rendering.
**Exploitation:** Attacker controls the GitHub hostname supplied to the import API, returns a malicious label color, and the victim visiting the labels page executes attacker JS in gitlab.com origin despite CSP.
**Insight:** Import/migration endpoints that accept a user-supplied source hostname let you feed arbitrary field values past the real provider's validation; target color/style fields rendered into CSS or HTML for CSP-bypassing payloads.
