Async Http Client
Monthly
Cross-host request replay in AsyncHttpClient (AHC) before 3.0.13 and 2.16.1 can disclose the original origin's request path, Host header, Authorization credentials, or even a plaintext request to a completely different destination when an application's ResponseFilter fails over or retries a request onto a different base origin (host, scheme, or port) or downgrades HTTPS to HTTP. The assessed vector is unauthenticated from the network perspective (PR:N, AV:N), but exploitation hinges on a concrete application-side prerequisite: a ResponseFilter (or equivalent retry/failover code path) that replays requests across origins - default AHC usage with same-host retries is unaffected, and AC:H/AT:P reflect the specific sequencing that must occur. No public exploit code and no confirmed active exploitation were identified at time of analysis, and because the impact depends on configuration rather than an attacker-reachable endpoint, the CVSS 4.0 score of 9.4 and the independent CVSS 3.1 assessment point in different directions; prioritization should be driven by whether a cross-host replaying filter is deployed.
Connection-pool reuse in the AsyncHttpClient (AHC) Java library, versions prior to 3.0.13 and 2.16.1, lets an authenticated principal inherit an HTTP/1.1 socket that was authenticated by a different principal under NTLM, Kerberos, or SPNEGO/Negotiate, causing the backend to execute the second request as the first identity - a full read/act-as impersonation (VC:H/VI:H). The flaw is that the connection-pool partition key omits the authenticated principal for connection-oriented authentication schemes, while Basic and Digest, which authenticate every request, are not affected. Exploitation requires an authenticated user (PR:L) on a deployment that shares one client/pool across multiple identities, and it is timing-dependent (AC:H, AT:P) because a suitably authenticated pooled socket must exist and be handed to the mismatched request; no public exploit code was identified at time of analysis and there is no KEV entry, though EPSS data was not provided. The vendor-released patch is AsyncHttpClient 3.0.13 (3.x line) or 2.16.1 (2.x line).
Digest mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.12 allows a rogue or on-path peer to be accepted as the authenticated server: when a Digest challenge advertises qop="auth-int" as the only supported quality-of-protection, the client negotiates it but cannot compute the expected rspauth, treats that as unverifiable-but-nonfatal, and accepts a response whose rspauth value is invalid. The flaw is network-reachable, unauthenticated and requires no user interaction (CVSS 4.0 AV:N/AC:L/PR:N/UI:N, 8.8), with the primary impact on integrity (VI:H) consistent with server impersonation rather than the data theft implied by the 'Information Disclosure' tag. It only affects applications that use AHC's Digest Realm with mutual authentication and connect to a peer offering an auth-int-only challenge; deployments where the server offers 'auth' or 'auth,auth-int' are unaffected because AHC prefers and verifies 'auth'. No public exploit code and no confirmed active exploitation were identified at time of analysis; the vendor-released patch is version 3.0.13.
Cleartext credential disclosure in AsyncHttpClient (AHC) before 3.0.12 on the 3.x line and before 2.16.1 on the 2.x line causes a client configured to use an HTTP proxy to write the origin request and its Authorization credentials onto a still-plaintext proxy connection when the proxy rejects the CONNECT with anything other than 200, because the client infers an established tunnel from the last request method rather than the CONNECT result. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5 HIGH), this is an unauthenticated, confidentiality-only issue: Basic credentials can be recovered directly, while NTLM responses may be cracked or relayed. Exploitation is limited to environments where the victim application routes through an HTTP proxy and the attacker controls or can man-in-the-middle the client-to-proxy hop; no public exploit identified at time of analysis.
Credential disclosure in the AsyncHttpClient (AHC) Java library allows a malicious or compromised origin server or proxy to capture plaintext-recoverable usernames and passwords from applications that configure HTTP credentials via Realm.Builder. When the attacker returns a WWW-Authenticate or Proxy-Authenticate challenge labeled 'Digest' but with the nonce parameter omitted or empty, versions prior to 3.0.13 (3.x) and 2.16.1 (2.x) silently fall back to Basic authentication and resend the credentials in reversible Base64, defeating the entire purpose of Digest. Exploitation is unauthenticated from the network (CVSS v4.0 8.7, AV:N/PR:N, independent assessment CVSS v3.1 C:H/I:N/A:N), but requires the attacker to control or tamper with the authentication challenge, so it is not exploitable against arbitrary endpoints; no public exploit code or CISA KEV entry was identified at time of analysis.
Connection-pool key scoping in AsyncHttpClient (AHC) 2.0.0 through 3.0.13 omits identity-defining fields for Kerberos, SPNEGO, NTLM, authenticated proxy and SOCKS/CONNECT login paths, so a request can be handed a pooled keep-alive socket that was already authenticated as an entirely different identity and then execute under that first identity's credentials, exposing the other identity's data or authority. Reachability is conditional: the application must use Kerberos/SPNEGO/NTLM, an authenticated proxy realm, or SOCKS/CONNECT proxy logins, and specifically the ambiguous cases where login has no configured principal, where realms are proxy realms, where distinct identities share a user name, or where proxy logins are used - clients using only HTTP Basic/Digest or a single identity/principal are not affected. Rated CVSS 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, CWE-346 Origin Validation Error); exploitation depends on timing the reuse of an already-authenticated socket across multiplexed callers, and there is no public exploit identified at time of analysis and no CISA KEV listing. Vendor-released patch: 3.0.14.
Unbounded WebSocket permessage-deflate decompression in the AsyncHttpClient (AHC) Java library versions 2.2.0 through 3.0.13 allows a malicious or compromised WebSocket peer to exhaust the JVM heap of the connecting application by sending a small compressed message that inflates into a very large Netty buffer. The flaw is remote, requires no authentication or user interaction from the peer side (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), but it only triggers when the client application itself opens an outbound WebSocket connection with permessage-deflate compression negotiated - meaning the victim must connect to an attacker-controlled endpoint or be exposed to a man-in-the-middle. Impact is availability-only: no confidentiality or integrity loss, and no public exploit code has been identified at time of analysis. The issue is fixed in version 3.0.14.
Heap exhaustion in AsyncHttpClient (AHC) 2.0.0 through 2.16.0 and 3.x before 3.0.12 allows any server the client calls - or anyone able to rewrite a response in transit - to kill the client JVM by returning a small gzip, deflate, or snappy body that inflates without bound across chunks until the process raises OutOfMemoryError. The vulnerable path is automatic response decompression on HTTP/1.1, and on releases 3.0.8 through 3.0.10 the HTTP/2 decompressor is unbounded as well, so switching protocols does not mitigate; brotli and zstd are also affected when those optional codecs are on the classpath. This is an availability-only issue (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/A:H) with no public exploit identified at time of analysis, and realistic exposure is limited to deployments that make outbound HTTP requests to untrusted, attacker-influenceable, or user-supplied URLs.
AsyncHttpClient (AHC) 2.1.0 through 2.16.0 and 3.0.x before 3.0.12 can disclose authenticated SOCKS proxy credentials - including directly reversible Basic credentials and NTLM/Kerberos/SPNEGO material - to the origin server because the library attaches a Proxy-Authorization header to a request carried over a SOCKS tunnel without first confirming that the destination is an HTTP proxy. Any Java application that configures AHC with an authenticated SOCKS4 or SOCKS5 proxy in those versions is exposed: in the preemptive-authentication path the header is emitted on plaintext HTTP requests to any origin, and in the default non-preemptive path a hostile origin that answers with HTTP 407 triggers ProxyUnauthorized407Interceptor to push the proxy credentials back through the tunnel to that origin. The reporter-assigned CVSS is 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), a confidentiality-only, high-impact issue that requires an authenticated SOCKS proxy configuration to be present; no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.
Local information disclosure and symlink-following file overwrite in AsyncHttpClient versions 2.0.0 through 2.16.0 and 3.x before 3.0.12 let an authenticated local user on a shared multi-user host read resumable download URLs - including embedded credentials and query tokens - from a predictably named store at $java.io.tmpdir/ahc/ResumableAsyncHandler.properties, or plant a symbolic link that the client follows when saving state, truncating and overwriting any file writable by the client process. Only applications that decorate another AsyncHandler with ResumableAsyncHandler backed by PropertiesBasedResumableProcessor are exposed; the no-argument constructors use a no-op processor and are unaffected. Exploitation requires local access, control of the shared $java.io.tmpdir/ahc directory, and timing against a state save; no public exploit code was identified at time of analysis and there is no KEV confirmation of active exploitation. The issue is fixed in 2.16.1 and 3.0.12.
Proxied plaintext WebSocket (ws://) requests issued through AsyncHttpClient before 3.0.12 or 2.16.1 leak the configured proxy's credentials to the origin WebSocket server. When an HTTP proxy requiring authentication is in use, the tunneled ws:// upgrade is built with the proxy's Proxy-Authorization header and an absolute-form request target, so the origin endpoint operator - or any party able to observe origin-bound traffic - can recover Basic credentials directly or capture a Digest challenge-response for offline cracking or replay. Exploitation depends on a non-default configuration (an authenticated HTTP proxy plus an application-initiated ws:// request), yields only proxy credentials rather than user or application data, and is rated CVSS 3.1 base 5.9; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Improper verification of the WebSocket opening handshake in AsyncHttpClient (AHC) versions prior to 3.0.12 and 2.16.1 lets a malicious or man-in-the-middle WebSocket endpoint have frames decoded and delivered to the application's WebSocketListener even though the server's Sec-WebSocket-Accept value was missing or invalid and the 101 upgrade was never authenticated. Only Java applications that use the WebSocketUpgradeHandler on an affected AHC release and connect to an attacker-controlled or intercepted endpoint are exposed, and because the request future still fails and the channel is closed the window for delivering coalesced frames is narrow and the impact is limited to integrity of listener-delivered data. No public exploit code has been identified at time of analysis and the issue is not known to be actively exploited, consistent with its low CVSS 3.1 score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
HTTP Digest authentication in AsyncHttpClient (Java) prior to 3.0.12 and 2.16.1 derives the client nonce (cnonce) from ThreadLocalRandom rather than a cryptographically secure source, weakening the Digest exchange against chosen-plaintext and credential-precomputation attacks for an observer who can infer generator state. The issue is rated CVSS 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N), so per the assessed vector no authentication is required from a remote attacker, but exploitation is statistical and high-complexity rather than a direct exploit. Only applications that use AsyncHttpClient's Digest auth via Realm.Builder are affected; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV is not indicated).
Cross-origin cookie injection in AsyncHttpClient (AHC) Java library before 3.0.13 and 2.16.1 allows an attacker-controlled host beneath a registry-level public suffix such as co.uk to set a cookie for that suffix itself, which the shared ThreadSafeCookieStore then replays to unrelated hosts under the same suffix. The failure lies in ThreadSafeCookieStore, which performs domain matching but never applies the RFC 6265 Section 5.3 step 5 rule that rejects a Domain attribute naming a public suffix; the practical result is that session-relevant cookie values can be injected or overwritten across origins sharing that registry. Impact is integrity-only (I:H, no confidentiality or availability loss) and exploitation is scenario-dependent, requiring one cookie store shared across requests to both an attacker host and a victim host under the same suffix, which is why the assessed vector carries High attack complexity and a present Attack Requirement. No public exploit code or active exploitation was identified at time of analysis; fixes are released as version 3.0.13 and 2.16.1.
AsyncHttpClient (AHC), a Java library for asynchronous HTTP requests, contains an incomplete cookie Domain validation flaw in its ThreadSafeCookieStore: from 2.16.0 through 2.16.1 and from 3.0.11 through 3.0.13, the store fails to apply private-section and default public-suffix rules, A-label (IDN) normalization, locale-independent lowercasing, and proper host-only and numeric/IP host checks, so a cookie set by one origin can be stored and later replayed to a different origin. Applications that share a single client instance across distinct trust domains can therefore receive attacker-injected cookies and may be exposed to session fixation; the assessed impact is integrity-only (CVSS 3.1 4.0, AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N) with no data disclosure. Exploitation is constrained by a non-default deployment pattern (per-origin or per-trust-boundary clients are not affected) and by the attacker needing to control or inject a Set-Cookie response from one of the shared origins; no public exploit code was identified at time of analysis, and the vendor has released a fix in version 3.0.14.
Cookie-store handling in AsyncHttpClient (AHC) versions 2.1.0 through 2.16.1 and 3.0.0 through 3.0.13 lets a shared client instance attach one user's stored cookies to another user's request, causing the outbound request to execute under the wrong session. The enabled-by-default cookie store replaces a Cookie header set explicitly via setHeader or addHeader whenever the store holds any cookie for the origin, a gap that survives the earlier CVE-2024-53990 fix (which only covered cookies supplied through addCookie). Exploitation is conditional rather than broadly weaponizable: it requires a multi-tenant shared client, an authenticated participant (CVSS PR:L), at least one caller supplying the Cookie header directly, and a stored cookie for the same origin, with timing/ordering dependence reflected in the high attack complexity (AC:H) of the assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N vector; no public exploit identified at time of analysis and no CISA KEV listing. A vendor-released patch, version 3.0.14, is available.
Mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.8 through 3.0.11 allows a man-in-the-middle who cannot prove knowledge of the shared secret to be accepted as a legitimate server when SCRAM-SHA-256 or Digest mutual authentication is used over a non-TLS or already-compromised transport. The affected interceptor methods computed the SCRAM ServerSignature or Digest rspauth verification value but only logged a mismatch and still delivered the response to the application as authenticated, so the client silently loses its only signal that the peer is an impostor. Over TLS the flaw is inert because a genuine server always returns a valid verification value; exploitation requires a MITM position (AC:H), the impact is limited to authentication-assurance loss (C:N/I:L/A:N), and no public exploit code or active exploitation has been identified at time of analysis. Fixed in version 3.0.12.
Cleartext exposure of origin credentials in AsyncHttpClient (AHC) 2.0.0-2.16.0 and 3.0.0-3.0.11 occurs when a Java application reaches an HTTPS origin through an HTTP CONNECT proxy while using preemptive origin authentication: the library attaches the origin's Authorization header - Basic or Digest credentials, plus per-connection NTLM/Kerberos/SPNEGO tokens - to the plaintext CONNECT request before any TLS tunnel exists, so the proxy and any observer on the client-to-proxy hop can read credentials meant only for the origin. The vulnerability is rated CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but a high attack-complexity qualifier, because exploitation requires the specific non-default combination of a CONNECT proxy, preemptive origin authentication, and an adversary positioned on that network segment; authentication requirements are not confirmed from the supplied vector beyond PR:N, and there is no public exploit identified at time of analysis. Vendor-released patches are 2.16.1 and 3.0.12, and because 3.0.12 is itself affected by a separate Digest-to-Basic downgrade flaw (GHSA-rqf5-2wxv-rjf4), 3.0.13 is the recommended target on the 3.x line.
Connection-permit leakage in the AsyncHttpClient (AHC) Java library versions 3.0.8 through 3.0.11 can permanently exhaust a configured connection pool and deny service to subsequent HTTP requests. Applications are exposed only if they set maxConnections or maxConnectionsPerHost above zero; each TLS connection attempt that aborts before the handshake completes strands one permit, because NettyConnectListener removes the partitionKeyLock permit from NettyResponseFuture before every failure path is bound to the channel's closeFuture. Repeated pre-handshake TLS failures can lock out a single host under a per-host limit or drain the shared pool under a global limit even when no connection remains open; the default unlimited setting is not affected, no public exploit code was identified at time of analysis, and the issue is fixed in 3.0.12.
Credential disclosure in AsyncHttpClient (Java) allows a client configured with a client-wide Realm via config.setRealm(...) and with redirect following enabled to leak Basic, Digest, Negotiate, or NTLM credentials to an attacker-controlled origin. When a cross-origin or scheme-downgrade redirect clears the per-exchange realm, the authentication interceptor in Interceptors.java falls back to config.getRealm() and re-attaches the client-wide credentials; if the attacker's target then answers HTTP 401, the client sends those credentials or tokens to that foreign origin. Affected releases are 2.14.5 through 2.16.0 and 3.0.9 through 3.0.11, fixed in 2.16.1 and 3.0.12; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the flaw is conditional on the specific client-wide Realm configuration, redirect following, attacker-influenced redirect, and a 401 response (AC:H per the assessed vector).
Cookie tossing in AsyncHttpClient (AHC) library allows a malicious HTTP server to plant cookies scoped to an unrelated trusted domain, affecting versions 2.0.0-2.15.x and 3.0.0.Beta1-3.0.10. ThreadSafeCookieStore accepts and stores a cookie's Domain attribute value without verifying that the responding host is authorised to set cookies for that domain, so any server the client contacts can inject a cookie that AHC will automatically forward to the targeted domain on subsequent requests. Java applications sharing a single AHC instance - and therefore its default shared CookieStore - across calls to both attacker-influenced and trusted hosts are the primary attack surface; no public exploit has been identified at time of analysis, and vendor-released fixes are available in 2.16.0 and 3.0.11.
AsyncHttpClient (AHC) library prior to versions 3.0.9 and 2.14.5 leaks Authorization, Proxy-Authorization headers, and plaintext Realm credentials to arbitrary redirect targets when followRedirect(true) is enabled, affecting all Java applications using vulnerable versions. This occurs across domain, scheme, and port changes including HTTPS-to-HTTP downgrades. An attacker controlling a redirect destination via open redirect, DNS rebinding, or MITM can capture Bearer tokens, Basic auth credentials, or any Authorization header value. No public exploit code or active exploitation has been confirmed at analysis time, though the vulnerability is exploitable with high-confidence conditions when redirect following is enabled (CVSS 6.8, network vector, no authentication required).
Versions of Async HTTP Client prior to 1.13.2 are vulnerable to a form of targeted request manipulation called CRLF injection. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Async Http Client (aka async-http-client) before 2.0.35 can be tricked into connecting to a host different from the one extracted by java.net.URI if a '?' character occurs in a fragment identifier. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
main/java/com/ning/http/client/AsyncHttpClientConfig.java in Async Http Client (aka AHC or async-http-client) before 1.9.0 does not require a hostname match during verification of X.509 certificates,. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable.
Async Http Client (aka AHC or async-http-client) before 1.9.0 skips X.509 certificate verification unless both a keyStore location and a trustStore location are explicitly set, which allows. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable.
Cross-host request replay in AsyncHttpClient (AHC) before 3.0.13 and 2.16.1 can disclose the original origin's request path, Host header, Authorization credentials, or even a plaintext request to a completely different destination when an application's ResponseFilter fails over or retries a request onto a different base origin (host, scheme, or port) or downgrades HTTPS to HTTP. The assessed vector is unauthenticated from the network perspective (PR:N, AV:N), but exploitation hinges on a concrete application-side prerequisite: a ResponseFilter (or equivalent retry/failover code path) that replays requests across origins - default AHC usage with same-host retries is unaffected, and AC:H/AT:P reflect the specific sequencing that must occur. No public exploit code and no confirmed active exploitation were identified at time of analysis, and because the impact depends on configuration rather than an attacker-reachable endpoint, the CVSS 4.0 score of 9.4 and the independent CVSS 3.1 assessment point in different directions; prioritization should be driven by whether a cross-host replaying filter is deployed.
Connection-pool reuse in the AsyncHttpClient (AHC) Java library, versions prior to 3.0.13 and 2.16.1, lets an authenticated principal inherit an HTTP/1.1 socket that was authenticated by a different principal under NTLM, Kerberos, or SPNEGO/Negotiate, causing the backend to execute the second request as the first identity - a full read/act-as impersonation (VC:H/VI:H). The flaw is that the connection-pool partition key omits the authenticated principal for connection-oriented authentication schemes, while Basic and Digest, which authenticate every request, are not affected. Exploitation requires an authenticated user (PR:L) on a deployment that shares one client/pool across multiple identities, and it is timing-dependent (AC:H, AT:P) because a suitably authenticated pooled socket must exist and be handed to the mismatched request; no public exploit code was identified at time of analysis and there is no KEV entry, though EPSS data was not provided. The vendor-released patch is AsyncHttpClient 3.0.13 (3.x line) or 2.16.1 (2.x line).
Digest mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.12 allows a rogue or on-path peer to be accepted as the authenticated server: when a Digest challenge advertises qop="auth-int" as the only supported quality-of-protection, the client negotiates it but cannot compute the expected rspauth, treats that as unverifiable-but-nonfatal, and accepts a response whose rspauth value is invalid. The flaw is network-reachable, unauthenticated and requires no user interaction (CVSS 4.0 AV:N/AC:L/PR:N/UI:N, 8.8), with the primary impact on integrity (VI:H) consistent with server impersonation rather than the data theft implied by the 'Information Disclosure' tag. It only affects applications that use AHC's Digest Realm with mutual authentication and connect to a peer offering an auth-int-only challenge; deployments where the server offers 'auth' or 'auth,auth-int' are unaffected because AHC prefers and verifies 'auth'. No public exploit code and no confirmed active exploitation were identified at time of analysis; the vendor-released patch is version 3.0.13.
Cleartext credential disclosure in AsyncHttpClient (AHC) before 3.0.12 on the 3.x line and before 2.16.1 on the 2.x line causes a client configured to use an HTTP proxy to write the origin request and its Authorization credentials onto a still-plaintext proxy connection when the proxy rejects the CONNECT with anything other than 200, because the client infers an established tunnel from the last request method rather than the CONNECT result. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5 HIGH), this is an unauthenticated, confidentiality-only issue: Basic credentials can be recovered directly, while NTLM responses may be cracked or relayed. Exploitation is limited to environments where the victim application routes through an HTTP proxy and the attacker controls or can man-in-the-middle the client-to-proxy hop; no public exploit identified at time of analysis.
Credential disclosure in the AsyncHttpClient (AHC) Java library allows a malicious or compromised origin server or proxy to capture plaintext-recoverable usernames and passwords from applications that configure HTTP credentials via Realm.Builder. When the attacker returns a WWW-Authenticate or Proxy-Authenticate challenge labeled 'Digest' but with the nonce parameter omitted or empty, versions prior to 3.0.13 (3.x) and 2.16.1 (2.x) silently fall back to Basic authentication and resend the credentials in reversible Base64, defeating the entire purpose of Digest. Exploitation is unauthenticated from the network (CVSS v4.0 8.7, AV:N/PR:N, independent assessment CVSS v3.1 C:H/I:N/A:N), but requires the attacker to control or tamper with the authentication challenge, so it is not exploitable against arbitrary endpoints; no public exploit code or CISA KEV entry was identified at time of analysis.
Connection-pool key scoping in AsyncHttpClient (AHC) 2.0.0 through 3.0.13 omits identity-defining fields for Kerberos, SPNEGO, NTLM, authenticated proxy and SOCKS/CONNECT login paths, so a request can be handed a pooled keep-alive socket that was already authenticated as an entirely different identity and then execute under that first identity's credentials, exposing the other identity's data or authority. Reachability is conditional: the application must use Kerberos/SPNEGO/NTLM, an authenticated proxy realm, or SOCKS/CONNECT proxy logins, and specifically the ambiguous cases where login has no configured principal, where realms are proxy realms, where distinct identities share a user name, or where proxy logins are used - clients using only HTTP Basic/Digest or a single identity/principal are not affected. Rated CVSS 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, CWE-346 Origin Validation Error); exploitation depends on timing the reuse of an already-authenticated socket across multiplexed callers, and there is no public exploit identified at time of analysis and no CISA KEV listing. Vendor-released patch: 3.0.14.
Unbounded WebSocket permessage-deflate decompression in the AsyncHttpClient (AHC) Java library versions 2.2.0 through 3.0.13 allows a malicious or compromised WebSocket peer to exhaust the JVM heap of the connecting application by sending a small compressed message that inflates into a very large Netty buffer. The flaw is remote, requires no authentication or user interaction from the peer side (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), but it only triggers when the client application itself opens an outbound WebSocket connection with permessage-deflate compression negotiated - meaning the victim must connect to an attacker-controlled endpoint or be exposed to a man-in-the-middle. Impact is availability-only: no confidentiality or integrity loss, and no public exploit code has been identified at time of analysis. The issue is fixed in version 3.0.14.
Heap exhaustion in AsyncHttpClient (AHC) 2.0.0 through 2.16.0 and 3.x before 3.0.12 allows any server the client calls - or anyone able to rewrite a response in transit - to kill the client JVM by returning a small gzip, deflate, or snappy body that inflates without bound across chunks until the process raises OutOfMemoryError. The vulnerable path is automatic response decompression on HTTP/1.1, and on releases 3.0.8 through 3.0.10 the HTTP/2 decompressor is unbounded as well, so switching protocols does not mitigate; brotli and zstd are also affected when those optional codecs are on the classpath. This is an availability-only issue (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/A:H) with no public exploit identified at time of analysis, and realistic exposure is limited to deployments that make outbound HTTP requests to untrusted, attacker-influenceable, or user-supplied URLs.
AsyncHttpClient (AHC) 2.1.0 through 2.16.0 and 3.0.x before 3.0.12 can disclose authenticated SOCKS proxy credentials - including directly reversible Basic credentials and NTLM/Kerberos/SPNEGO material - to the origin server because the library attaches a Proxy-Authorization header to a request carried over a SOCKS tunnel without first confirming that the destination is an HTTP proxy. Any Java application that configures AHC with an authenticated SOCKS4 or SOCKS5 proxy in those versions is exposed: in the preemptive-authentication path the header is emitted on plaintext HTTP requests to any origin, and in the default non-preemptive path a hostile origin that answers with HTTP 407 triggers ProxyUnauthorized407Interceptor to push the proxy credentials back through the tunnel to that origin. The reporter-assigned CVSS is 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), a confidentiality-only, high-impact issue that requires an authenticated SOCKS proxy configuration to be present; no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.
Local information disclosure and symlink-following file overwrite in AsyncHttpClient versions 2.0.0 through 2.16.0 and 3.x before 3.0.12 let an authenticated local user on a shared multi-user host read resumable download URLs - including embedded credentials and query tokens - from a predictably named store at $java.io.tmpdir/ahc/ResumableAsyncHandler.properties, or plant a symbolic link that the client follows when saving state, truncating and overwriting any file writable by the client process. Only applications that decorate another AsyncHandler with ResumableAsyncHandler backed by PropertiesBasedResumableProcessor are exposed; the no-argument constructors use a no-op processor and are unaffected. Exploitation requires local access, control of the shared $java.io.tmpdir/ahc directory, and timing against a state save; no public exploit code was identified at time of analysis and there is no KEV confirmation of active exploitation. The issue is fixed in 2.16.1 and 3.0.12.
Proxied plaintext WebSocket (ws://) requests issued through AsyncHttpClient before 3.0.12 or 2.16.1 leak the configured proxy's credentials to the origin WebSocket server. When an HTTP proxy requiring authentication is in use, the tunneled ws:// upgrade is built with the proxy's Proxy-Authorization header and an absolute-form request target, so the origin endpoint operator - or any party able to observe origin-bound traffic - can recover Basic credentials directly or capture a Digest challenge-response for offline cracking or replay. Exploitation depends on a non-default configuration (an authenticated HTTP proxy plus an application-initiated ws:// request), yields only proxy credentials rather than user or application data, and is rated CVSS 3.1 base 5.9; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Improper verification of the WebSocket opening handshake in AsyncHttpClient (AHC) versions prior to 3.0.12 and 2.16.1 lets a malicious or man-in-the-middle WebSocket endpoint have frames decoded and delivered to the application's WebSocketListener even though the server's Sec-WebSocket-Accept value was missing or invalid and the 101 upgrade was never authenticated. Only Java applications that use the WebSocketUpgradeHandler on an affected AHC release and connect to an attacker-controlled or intercepted endpoint are exposed, and because the request future still fails and the channel is closed the window for delivering coalesced frames is narrow and the impact is limited to integrity of listener-delivered data. No public exploit code has been identified at time of analysis and the issue is not known to be actively exploited, consistent with its low CVSS 3.1 score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
HTTP Digest authentication in AsyncHttpClient (Java) prior to 3.0.12 and 2.16.1 derives the client nonce (cnonce) from ThreadLocalRandom rather than a cryptographically secure source, weakening the Digest exchange against chosen-plaintext and credential-precomputation attacks for an observer who can infer generator state. The issue is rated CVSS 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N), so per the assessed vector no authentication is required from a remote attacker, but exploitation is statistical and high-complexity rather than a direct exploit. Only applications that use AsyncHttpClient's Digest auth via Realm.Builder are affected; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV is not indicated).
Cross-origin cookie injection in AsyncHttpClient (AHC) Java library before 3.0.13 and 2.16.1 allows an attacker-controlled host beneath a registry-level public suffix such as co.uk to set a cookie for that suffix itself, which the shared ThreadSafeCookieStore then replays to unrelated hosts under the same suffix. The failure lies in ThreadSafeCookieStore, which performs domain matching but never applies the RFC 6265 Section 5.3 step 5 rule that rejects a Domain attribute naming a public suffix; the practical result is that session-relevant cookie values can be injected or overwritten across origins sharing that registry. Impact is integrity-only (I:H, no confidentiality or availability loss) and exploitation is scenario-dependent, requiring one cookie store shared across requests to both an attacker host and a victim host under the same suffix, which is why the assessed vector carries High attack complexity and a present Attack Requirement. No public exploit code or active exploitation was identified at time of analysis; fixes are released as version 3.0.13 and 2.16.1.
AsyncHttpClient (AHC), a Java library for asynchronous HTTP requests, contains an incomplete cookie Domain validation flaw in its ThreadSafeCookieStore: from 2.16.0 through 2.16.1 and from 3.0.11 through 3.0.13, the store fails to apply private-section and default public-suffix rules, A-label (IDN) normalization, locale-independent lowercasing, and proper host-only and numeric/IP host checks, so a cookie set by one origin can be stored and later replayed to a different origin. Applications that share a single client instance across distinct trust domains can therefore receive attacker-injected cookies and may be exposed to session fixation; the assessed impact is integrity-only (CVSS 3.1 4.0, AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N) with no data disclosure. Exploitation is constrained by a non-default deployment pattern (per-origin or per-trust-boundary clients are not affected) and by the attacker needing to control or inject a Set-Cookie response from one of the shared origins; no public exploit code was identified at time of analysis, and the vendor has released a fix in version 3.0.14.
Cookie-store handling in AsyncHttpClient (AHC) versions 2.1.0 through 2.16.1 and 3.0.0 through 3.0.13 lets a shared client instance attach one user's stored cookies to another user's request, causing the outbound request to execute under the wrong session. The enabled-by-default cookie store replaces a Cookie header set explicitly via setHeader or addHeader whenever the store holds any cookie for the origin, a gap that survives the earlier CVE-2024-53990 fix (which only covered cookies supplied through addCookie). Exploitation is conditional rather than broadly weaponizable: it requires a multi-tenant shared client, an authenticated participant (CVSS PR:L), at least one caller supplying the Cookie header directly, and a stored cookie for the same origin, with timing/ordering dependence reflected in the high attack complexity (AC:H) of the assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N vector; no public exploit identified at time of analysis and no CISA KEV listing. A vendor-released patch, version 3.0.14, is available.
Mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.8 through 3.0.11 allows a man-in-the-middle who cannot prove knowledge of the shared secret to be accepted as a legitimate server when SCRAM-SHA-256 or Digest mutual authentication is used over a non-TLS or already-compromised transport. The affected interceptor methods computed the SCRAM ServerSignature or Digest rspauth verification value but only logged a mismatch and still delivered the response to the application as authenticated, so the client silently loses its only signal that the peer is an impostor. Over TLS the flaw is inert because a genuine server always returns a valid verification value; exploitation requires a MITM position (AC:H), the impact is limited to authentication-assurance loss (C:N/I:L/A:N), and no public exploit code or active exploitation has been identified at time of analysis. Fixed in version 3.0.12.
Cleartext exposure of origin credentials in AsyncHttpClient (AHC) 2.0.0-2.16.0 and 3.0.0-3.0.11 occurs when a Java application reaches an HTTPS origin through an HTTP CONNECT proxy while using preemptive origin authentication: the library attaches the origin's Authorization header - Basic or Digest credentials, plus per-connection NTLM/Kerberos/SPNEGO tokens - to the plaintext CONNECT request before any TLS tunnel exists, so the proxy and any observer on the client-to-proxy hop can read credentials meant only for the origin. The vulnerability is rated CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but a high attack-complexity qualifier, because exploitation requires the specific non-default combination of a CONNECT proxy, preemptive origin authentication, and an adversary positioned on that network segment; authentication requirements are not confirmed from the supplied vector beyond PR:N, and there is no public exploit identified at time of analysis. Vendor-released patches are 2.16.1 and 3.0.12, and because 3.0.12 is itself affected by a separate Digest-to-Basic downgrade flaw (GHSA-rqf5-2wxv-rjf4), 3.0.13 is the recommended target on the 3.x line.
Connection-permit leakage in the AsyncHttpClient (AHC) Java library versions 3.0.8 through 3.0.11 can permanently exhaust a configured connection pool and deny service to subsequent HTTP requests. Applications are exposed only if they set maxConnections or maxConnectionsPerHost above zero; each TLS connection attempt that aborts before the handshake completes strands one permit, because NettyConnectListener removes the partitionKeyLock permit from NettyResponseFuture before every failure path is bound to the channel's closeFuture. Repeated pre-handshake TLS failures can lock out a single host under a per-host limit or drain the shared pool under a global limit even when no connection remains open; the default unlimited setting is not affected, no public exploit code was identified at time of analysis, and the issue is fixed in 3.0.12.
Credential disclosure in AsyncHttpClient (Java) allows a client configured with a client-wide Realm via config.setRealm(...) and with redirect following enabled to leak Basic, Digest, Negotiate, or NTLM credentials to an attacker-controlled origin. When a cross-origin or scheme-downgrade redirect clears the per-exchange realm, the authentication interceptor in Interceptors.java falls back to config.getRealm() and re-attaches the client-wide credentials; if the attacker's target then answers HTTP 401, the client sends those credentials or tokens to that foreign origin. Affected releases are 2.14.5 through 2.16.0 and 3.0.9 through 3.0.11, fixed in 2.16.1 and 3.0.12; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the flaw is conditional on the specific client-wide Realm configuration, redirect following, attacker-influenced redirect, and a 401 response (AC:H per the assessed vector).
Cookie tossing in AsyncHttpClient (AHC) library allows a malicious HTTP server to plant cookies scoped to an unrelated trusted domain, affecting versions 2.0.0-2.15.x and 3.0.0.Beta1-3.0.10. ThreadSafeCookieStore accepts and stores a cookie's Domain attribute value without verifying that the responding host is authorised to set cookies for that domain, so any server the client contacts can inject a cookie that AHC will automatically forward to the targeted domain on subsequent requests. Java applications sharing a single AHC instance - and therefore its default shared CookieStore - across calls to both attacker-influenced and trusted hosts are the primary attack surface; no public exploit has been identified at time of analysis, and vendor-released fixes are available in 2.16.0 and 3.0.11.
AsyncHttpClient (AHC) library prior to versions 3.0.9 and 2.14.5 leaks Authorization, Proxy-Authorization headers, and plaintext Realm credentials to arbitrary redirect targets when followRedirect(true) is enabled, affecting all Java applications using vulnerable versions. This occurs across domain, scheme, and port changes including HTTPS-to-HTTP downgrades. An attacker controlling a redirect destination via open redirect, DNS rebinding, or MITM can capture Bearer tokens, Basic auth credentials, or any Authorization header value. No public exploit code or active exploitation has been confirmed at analysis time, though the vulnerability is exploitable with high-confidence conditions when redirect following is enabled (CVSS 6.8, network vector, no authentication required).
Versions of Async HTTP Client prior to 1.13.2 are vulnerable to a form of targeted request manipulation called CRLF injection. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Async Http Client (aka async-http-client) before 2.0.35 can be tricked into connecting to a host different from the one extracted by java.net.URI if a '?' character occurs in a fragment identifier. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
main/java/com/ning/http/client/AsyncHttpClientConfig.java in Async Http Client (aka AHC or async-http-client) before 1.9.0 does not require a hostname match during verification of X.509 certificates,. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable.
Async Http Client (aka AHC or async-http-client) before 1.9.0 skips X.509 certificate verification unless both a keyStore location and a trustStore location are explicitly set, which allows. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable.