Source: async-http-client Version: 2.12.3-1 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for async-http-client. CVE-2026-85719[0]: | The AsyncHttpClient (AHC) library allows Java applications to easily | execute HTTP requests and asynchronously process HTTP responses. | From 2.1.0 until 2.16.1 and 3.0.12, requests using an authenticated | SOCKS proxy can expose the proxy's credentials to the origin because | NettyRequestFactory and NettyRequestSender attach Proxy- | Authorization without confirming that the request is being sent to | an HTTP proxy. With preemptive proxy authentication, the header is | attached to a plaintext HTTP request, exposing credentials such as | directly reversible Basic credentials to the origin. With the | default non-preemptive flow, a hostile origin can return a 407 | response and ProxyUnauthorized407Interceptor sends the proxy | credentials through the existing SOCKS tunnel, including NTLM, | Kerberos, and SPNEGO credentials. Releases before 2.1.0 lack SOCKS | proxy support. This issue is fixed in versions 2.16.1 and 3.0.12. CVE-2026-85720[1]: | The AsyncHttpClient (AHC) library allows Java applications to easily | execute HTTP requests and asynchronously process HTTP responses. | From 2.0.0 until 2.16.1 and 3.0.12, a request using an HTTP proxy to | reach an HTTPS origin can expose preemptive origin credentials | because NettyRequestFactory and | NettyRequestSender.sendRequestWithNewChannel attach Authorization to | the plaintext CONNECT request before the TLS tunnel exists. Basic or | Digest credentials and per-connection NTLM, Kerberos, or SPNEGO | tokens intended for the origin are therefore visible to the proxy | and to observers on the client-to-proxy hop. The tunneled request | still receives origin Authorization after the tunnel is established, | while Proxy-Authorization remains on CONNECT for its intended proxy | recipient. This issue is fixed in versions 2.16.1 and 3.0.12. CVE-2026-85721[2]: | The AsyncHttpClient (AHC) library allows Java applications to easily | execute HTTP requests and asynchronously process HTTP responses. | From 2.0.0 until 2.16.1 and 3.0.12, automatic response decompression | on the HTTP/1.1 path uses | ChannelManager.newHttpContentDecompressor() to install | Http1ContentDecompressor without a cumulative output-size limit. A | hostile or compromised server, or an attacker who can alter a | response in transit, can send a small gzip, deflate, or snappy | response that expands across chunks until the client exhausts its | heap and raises OutOfMemoryError; brotli and zstd are also affected | when their optional codecs are present. In versions 3.0.8 through | 3.0.10, the HTTP/2 decompressor is also unbounded, so switching | protocols does not mitigate the issue on those releases. A limit | applied to each decode call is insufficient because the response can | be delivered as many small chunks, so the fixed implementation | tracks total decompressed bytes for the whole response. This issue | is fixed in versions 2.16.1 and 3.0.12. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-85719 https://www.cve.org/CVERecord?id=CVE-2026-85719 [1] https://security-tracker.debian.org/tracker/CVE-2026-85720 https://www.cve.org/CVERecord?id=CVE-2026-85720 [2] https://security-tracker.debian.org/tracker/CVE-2026-85721 https://www.cve.org/CVERecord?id=CVE-2026-85721 Regards, Salvatore
