AsyncHttpClient vulnerabilities

Vulnerability in AsyncHttpClient (AHC) library before versions 3.0.13 and 2.16.1 allows cross-host request replay that updates the current request but leaves the target request and proxy context pointing to the original origin. This can send the original host's path, Host header, Authorization credentials, or plaintext request to the replay destination.

The AsyncHttpClient library allows Java applications to execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, PropertiesBasedResumableProcessor stores resumable download state at the predictable shared path $java.io.tmpdir/ahc/ResumableAsyncHandler.properties with default permissions and link-following file operations. A local user who can read the shared store can see download URLs, including embedded user information or query tokens. A local user who can write within or pre-create the affected shared store directory can plant a symbolic link that the client follows when saving state, truncating and overwriting a target file writable by the client process. The filesystem path is used when ResumableAsyncHandler decorates another AsyncHandler, while the no-argument constructors use a no-op processor and are unaffected. This issue is fixed in versions 2.16.1 and 3.0.12.

The AsyncHttpClient (AHC) library from version 2.1.0 until 3.0.14 does not retain whether a Set-Cookie response used a secure transport. The default ThreadSafeCookieStore accepts Secure cookies received over plaintext and permits insecure cookies to overlay or delete existing Secure cookies with matching scope. An attacker controlling a plaintext same-site response can plant, replace, or remove cookie state later sent to an HTTPS origin.

In the AsyncHttpClient (AHC) library prior to versions 3.0.12 and 2.16.1, a proxied ws request is carried through CONNECT, but NettyRequestFactory.newNettyRequest and requestUri decide whether to attach proxy authentication and an absolute-form target only from whether the URI is secure. Because ws is not marked secure, the tunneled WebSocket upgrade sent to the origin includes the proxy's Proxy-Authorization value. Basic credentials are directly recoverable and Digest responses can be replayed or cracked offline. This issue is fixed in versions 3.0.12 and 2.16.1.

The AsyncHttpClient (AHC) library prior to 3.0.12 and 2.16.1 has a vulnerability in WebSocketHandler.upgrade that aborts a handshake with missing or invalid Sec-WebSocket-Accept but continues into pipeline installation and onOpen delivery. Frames coalesced with the invalid 101 response can be decoded and delivered from a peer that did not prove the handshake, although the request future fails and the channel closes. This issue is fixed in versions 3.0.12 and 2.16.1.

The AsyncHttpClient (AHC) library before versions 3.0.12 and 2.16.1 generates the HTTP Digest client nonce using ThreadLocalRandom instead of a cryptographically secure random source. This makes the authentication mechanism vulnerable to chosen-plaintext and credential precomputation attacks.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, the HTTP/1.1 connection-pool key excludes the authenticated principal for connection-oriented NTLM and Negotiate authentication. A pooled socket authenticated for one request can be reused by a request carrying another principal, and the server executes that later request as the first identity. Basic and Digest are not affected because they authenticate each request. This issue is fixed in versions 3.0.13 and 2.16.1.

In the AsyncHttpClient (AHC) library prior to versions 3.0.13 and 2.16.1, ThreadSafeCookieStore validates Domain attributes with domain matching but does not reject public suffixes. A host beneath a suffix such as co.uk can set a cookie for that suffix, after which the shared cookie store sends it to unrelated hosts under the suffix. This can inject or overwrite session-relevant cookie values across origins. This issue is fixed in versions 3.0.13 and 2.16.1.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. In 3.0.12, a peer offering only Digest qop=auth-int causes mutual-authentication verification to be skipped. AuthenticatorUtils.computeExpectedRspAuth returns no expected value for auth-int, and Interceptors treats that result as unverifiable but nonfatal, so a response with an invalid rspauth value is accepted. A peer that does not know the shared secret can therefore be accepted as the authenticated server. This issue is fixed in version 3.0.13.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 on 3.x and 2.16.1 on 2.x, the client infers that an HTTP proxy tunnel exists from the last request method rather than the CONNECT result. After a proxy rejects CONNECT, redirect or authentication handlers can write an origin request and its Authorization credentials onto the still-plaintext proxy connection. Basic credentials can be recovered directly, while NTLM responses may be cracked or relayed. This issue is fixed in versions 3.0.12 and 2.16.1.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, Realm.Builder treats a Digest challenge that yields no usable nonce as a Basic challenge. A malicious origin or proxy can label a challenge Digest while omitting or emptying the nonce, causing the client to resend the username and password using reversible Basic authentication. Both origin and proxy challenge parsers are affected. This issue is fixed in versions 3.0.13 and 2.16.1.

The AsyncHttpClient (AHC) library versions 2.0.0 through 3.0.14 incorrectly partition the connection pool for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Missing identity-defining fields can allow reuse of a socket authenticated as a different identity, leading to a request being executed under the first identity and exposing its data or authority to another caller. This issue is fixed in version 3.0.14.

The AsyncHttpClient (AHC) library from 2.16.0 until 3.0.14 has incomplete validation of cookie Domain attributes in ThreadSafeCookieStore. Missing private-section and default public-suffix rules, absent A-label normalization, locale-sensitive lowercasing, public-suffix host-only handling, and numeric or IP host checks allow one origin to store a cookie later sent to another origin. Applications sharing one client across trust domains can therefore receive attacker-injected cookies and may be exposed to session fixation. This issue is fixed in version 3.0.14.

The AsyncHttpClient (AHC) library from 2.1.0 until 3.0.14 has an enabled-by-default cookie store that replaces a Cookie header explicitly supplied through setHeader or addHeader whenever the store contributes any cookie for the origin. In a shared client, stored cookies originating from one user can replace a different user's request cookie, causing the request to execute under the wrong session. This bypasses the earlier CVE-2024-53990 remediation, which covered cookies supplied through addCookie but not a directly supplied header. This issue is fixed in version 3.0.14.

The AsyncHttpClient (AHC) library versions 2.2.0 through 3.0.14 have unbounded WebSocket permessage-deflate decompression when compression is enabled. The inbound pipeline aggregates compressed frames before WebSocketClientCompressionHandler inflates them, so webSocketMaxFrameSize and webSocketMaxBufferSize do not bound decompressed output. A malicious WebSocket peer can send a small compressed message that expands to a very large Netty buffer and exhausts JVM heap. This issue is fixed in version 3.0.14.

The AsyncHttpClient (AHC) library versions 2.0.0 to 2.16.1 and 3.0.12 can leak origin credentials when using an HTTP proxy to reach an HTTPS origin. NettyRequestFactory and NettyRequestSender.sendRequestWithNewChannel attach Authorization to the plaintext CONNECT request before the TLS tunnel exists, exposing Basic or Digest credentials and per-connection NTLM, Kerberos, or SPNEGO tokens to the proxy and observers on the client-to-proxy hop.

The AsyncHttpClient (AHC) library in versions 3.0.8 through 3.0.12 does not enforce verification of SCRAM ServerSignature and Digest rspauth authentication results. On a non-TLS or compromised transport, an attacker can be accepted as the server without proving knowledge of the shared secret. The issue is fixed in version 3.0.12.

The AsyncHttpClient (AHC) library in versions from 2.0.0 until 2.16.1 and 3.0.12 installs the HTTP/1.1 response decompressor without a cumulative output-size limit. A hostile or compromised server 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, and in versions 3.0.8 through 3.0.10 the HTTP/2 decompressor is unbounded as well.

The AsyncHttpClient (AHC) library in versions from 2.1.0 until 2.16.1 and 3.0.12 can expose authenticated SOCKS proxy credentials to the origin server. The Proxy-Authorization header is attached without confirming the request is sent to an HTTP proxy, so preemptive authentication leaks plaintext credentials, and with the default flow a hostile origin can force NTLM, Kerberos, or SPNEGO credentials through the SOCKS tunnel via a 407 response.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 3.0.8 until 3.0.12, a client with maxConnections or maxConnectionsPerHost set above zero leaks one connection permit whenever TLS connection establishment fails before the handshake completes. NettyConnectListener removes the partitionKeyLock permit from NettyResponseFuture before every failure path is bound to the channel closeFuture, so an abort can leave the permit unreleased. Repeated failures can permanently lock out one host under a per-host limit or drain the shared pool under a global limit, blocking later requests even when no connection remains open. The default unlimited connection setting is not affected. This issue is fixed in version 3.0.12.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.14.5 to 2.16.0 and from 3.0.9 to 3.0.11, a client configured with a client-wide Realm and redirect following can disclose credentials after a cross-origin redirect because the Interceptors authentication path falls back to the client configuration after redirect handling clears the per-exchange realm. If the attacker-controlled target returns 401, the client can send Basic or Digest credentials or a Negotiate or NTLM token to that origin. Per-request realms are stripped correctly, and this issue is a residual bypass of the earlier cross-origin credential-stripping fixes. This issue is fixed in versions 2.16.1 and 3.0.12.

The AsyncHttpClient (AHC) library versions 2.0.0 through 2.15.0 and 3.0.0.Beta1 through 3.0.10 have a vulnerability in ThreadSafeCookieStore that does not verify whether the responding host is allowed to set a cookie for a domain. This allows an attacker-controlled host to inject a cookie for an unrelated domain, which the client then sends to that domain.

The AsyncHttpClient (AHC) library versions 2.x before 2.15.0 and 3.x before 3.0.10 leak Cookie headers to cross-origin redirect targets. During a redirect to a different origin, the Cookie header is not stripped, allowing session cookies to be sent to attacker-controlled servers. Fixed in versions 2.15.0 and 3.0.10.