# All functions that allow users to specify color code are vulnerable to ReDoS

ReDoS in GitLab's color validator regex lets an authenticated user submit a crafted label color and exhaust server CPU, causing service-wide DoS.

- Payout: $1,000
- Severity: low
- Program: GitLab
- Credited: 8ayac
- Disclosed: 2019-08-21
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/511381
- Library page: https://bugbountylibrary.com/r/h1%3A511381
- Tags: domain:web impact:dos kind:bounty platform:hackerone sev:low tech:ruby technique:source-review vuln:dos

**Target:** GitLab color validator (app/validators/color_validator.rb) used by labels and broadcast messages
**Root cause:** The color validation regex in color_validator.rb has catastrophic backtracking on long crafted input, causing exponential CPU consumption.
**Steps:**
1. Create a project and open `/{userid}/{Project Name}/labels/new`.
2. Fill Title with `PoC` and submit, intercepting the request.
3. Replace `label[color]` with `#0` followed by 50000 `c` characters then `c0ffee`.
4. Forward the request; server CPU spikes above 90% and GitLab becomes unreachable.
5. Repeat requests to sustain the DoS.
**How found:** Researcher reviewed the color validator source, spotted the regex used to validate user-supplied color codes, and hypothesized catastrophic backtracking on long malformed input.
**Exploitation:** Any authenticated user submits a label creation request with a pathological color value; the validator regex backtracks catastrophically, pinning CPU and denying service to all users. Repeated requests keep the service down.
**Insight:** Any user-controlled field validated by a regex (color codes, slugs, IDs) is a ReDoS candidate; grep validators for nested quantifiers and test with long crafted prefixes before the matching suffix.