exposing HTTP/3 early data
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 8.14.2, 8.16.1, 8.20.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: yes
- Technical impact: partial
Summary
In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection before enforcing the certificate verification failure. Potentially leaking sensitive information.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: poc · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- curl curl
From 8.11.0 · fixed in 8.14.2; From 8.15.0 · fixed in 8.16.1; From 8.17.0 · fixed in 8.20.1
- curl curl
Version range not reported
- curl curl
8.20.0, 8.19.0, 8.18.0, 8.17.0, 8.16.0, 8.15.0, 8.14.1, 8.14.0, 8.13.0, 8.12.1, 8.12.0, 8.11.1, 8.11.0