# Unauthenticated blind SSRF in OAuth Jira authorization controller

Unauthenticated attacker controls Host header on GitLab's Jira OAuth callback, making the server POST to arbitrary internal hosts via oauth_token_url.

- Payout: $4,000
- Severity: high
- Program: GitLab
- Credited: jobert
- Disclosed: 2019-03-14
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/398799
- Library page: https://bugbountylibrary.com/r/h1%3A398799
- Tags: domain:web impact:dos impact:internal-access kind:bounty platform:hackerone sev:high tech:ruby technique:source-review vuln:host-header vuln:ssrf

**Target:** Oauth::Jira::AuthorizationsController#access_token endpoint
**Root cause:** The oauth_token_url Rails routing helper builds the token URL from the attacker-controlled Host header, and Gitlab::HTTP.post is called with allow_local_requests:true without validating the host, enabling blind SSRF.
**Steps:**
1. Spin up GitLab EE 11.2.1-ee
2. Send `curl -X POST -H 'Host: 162.243.147.21:81' 'https://gitlab.com/-/jira/login/oauth/access_token'`
3. Observe inbound POST from GitLab server IP to attacker listener on port 81
4. Response parsed as JSON for access_token/scope/token_type and reflected
**How found:** Noticed the access_token action passes oauth_token_url (a Rails _url helper derived from the Host header) directly into Gitlab::HTTP.post with allow_local_requests enabled, then tested by pointing Host at a controlled listener.
**Exploitation:** Unauthenticated POST with spoofed Host header causes GitLab to issue an HTTP POST to the attacker-chosen host:port; response JSON fields are reflected back, and a thread blocks up to 60s on TCP read timeout.
**Insight:** Rails `_url` helpers silently inherit the request Host header; any server-side HTTP call built from them is attacker-redirectable. Grep OAuth/token-exchange controllers for `_url` helpers passed to HTTP clients with local requests allowed.