REDHAT-BUG-2496756: Medium severity libcurl vulnerability
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 (CURLOPTSSLSESSIONIDCACHE is not disabled) and early data enabled (the CURLSSLOPTEARLYDATA bit is set in CURLOPTSSLOPTIONS), libcurl might send off the second request's bytes on that new connection before enforcing the certificate verification failure. Potentially leaking sensitive information.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for sensitive request data to be exposed?
The client must first connect to a legitimate HTTP/3 server, then reconnect to the same hostname after that server has been replaced by an attacker-controlled impostor without a valid certificate. SSL session caching must remain enabled and early data must be enabled through CURLSSLOPT_EARLYDATA.
Are default libcurl configurations affected?
The issue requires early data to be explicitly enabled with the CURLSSLOPT_EARLYDATA bit. It also requires CURLOPT_SSL_SESSIONID_CACHE not to be disabled.
What can be done if an update cannot be applied immediately?
Disable early data by removing the CURLSSLOPT_EARLYDATA option. Disabling the SSL session ID cache with CURLOPT_SSL_SESSIONID_CACHE also prevents the cached-session condition described for exploitation.
How can an application determine whether it is exposed?
Review its libcurl configuration for HTTP/3 use, enabled SSL session caching, and CURLSSLOPT_EARLYDATA in CURLOPT_SSL_OPTIONS. Exposure applies to requests that may contain sensitive bytes and are sent during a later connection to a hostname after a prior successful transfer.