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