# cURL / libcURL - CVE-2016-8624 invalid URL parsing with '#'

curl parsed the authority component incorrectly when the host ended with '#', so `http://example.com#@evil.com/x.txt` made curl connect to evil.com while RFC-compliant parsers saw example.com.

- Payout: $500
- Severity: medium
- Program: Internet Bug Bounty
- Credited: fms
- Disclosed: 2018-01-11
- CVE: CVE-2016-8624
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/180434
- Library page: https://bugbountylibrary.com/r/h1%3A180434
- Tags: domain:oss impact:internal-access kind:bounty platform:hackerone sev:medium tech:curl technique:parser-differential vuln:ssrf

**Target:** URL parser (authority component) in curl/libcurl
**Root cause:** curl's URL parser mishandled a '#' terminating the hostname portion of the authority, treating the remainder after '#' as part of the authority rather than as a fragment, causing a different host to be contacted than an RFC-compliant parser would resolve.
**Steps:**
1. Pass `http://example.com#@evil.com/x.txt` to curl
2. Observe curl connects to evil.com
3. Compare with a browser/RFC parser which resolves the same URL to example.com
**How found:** Researcher noticed curl's authority parsing diverged from RFC behavior when the hostname ends with '#', producing a parser differential exploitable against allowlist-based SSRF defenses.
**Exploitation:** An attacker supplies a URL that a validation layer (following RFC) parses as an allowed host (example.com) but that curl resolves to an attacker-controlled host (evil.com), bypassing allowlist checks and enabling SSRF to arbitrary hosts.
**Insight:** When a target validates URLs with one parser and fetches with curl, test '#' and '@' placement in the authority to create parser differentials that bypass domain allowlists.