# CVE-2022-42916: HSTS bypass via IDN

curl's HSTS check compared the raw URL hostname before IDN conversion, so a hostname using U+3002 ideographic full stops bypassed HSTS and forced cleartext HTTP.

- Payout: hidden
- Severity: medium
- Program: Internet Bug Bounty
- Found by: kurohiro
- Disclosed: 2022-11-03
- CVE: CVE-2022-42916
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1753226
- Library page: https://bugbountylibrary.com/r/h1%3A1753226
- Tags: area:oss domain:oss impact:data-leak kind:bounty platform:hackerone sev:medium tech:curl technique:unicode-normalization vuln:info-disclosure vuln:misconfiguration

**Target:** curl/libcurl HSTS enforcement and IDN hostname handling
**Root cause:** The HSTS lookup used the pre-IDN-conversion hostname, while the actual connection used the ASCII-converted hostname, so the HSTS entry for the ASCII host was never matched.
**Steps:**
1. Configure HSTS for a host, e.g. `curl --hsts hsts.txt https://curl.se` to populate the store
2. Request `http://curl。se。` using U+3002 IDEOGRAPHIC FULL STOP instead of ASCII dots
3. curl converts the IDN to `curl.se` for the connection but checks HSTS against the unconverted name
4. HSTS match fails and curl proceeds over cleartext HTTP instead of upgrading to HTTPS
**How found:** Likely noticed that HSTS matching and IDN conversion operated on different hostname representations; similar to prior CVE-2022-30115.
**Exploitation:** A network attacker who can intercept traffic exploits the victim's curl invocation using an IDN-encoded URL to prevent the HSTS upgrade, keeping the request in cleartext for interception.
**Insight:** When a security policy check (HSTS, allowlist, cookie domain) and the actual connection use different hostname normalization stages, feed the check a Unicode/IDN variant that normalizes to the protected host only after conversion.