Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
18 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact With the cookie store enabled, which is the default, a Cookie header that the caller sets on a request with setHeader or addHeader is thrown away whenever the store holds any cookie for the request's origin: the request's cookie list is written into that header afterwards and replaces it. CVE-2024-53990 fixed the same problem for cookies added with addCookie, but that fix works on the cookie list, and a header set directly never reaches it. This is not limited to a cookie of the same name. A store cookie of any name erases the caller's header, so a request meant to carry the caller's session cookie goes out with only the store's cookies, and where the store has a cookie of the caller's name, the store's value is sent instead. It matters most where one client acts for several users. An application that puts each user's session on the request itself, and shares one client and its default cookie store, sends one user's request with a session cookie the store took from a response…
Recommended action: Upgrade to 3.0.14; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The cookie store ignores the scheme a Set-Cookie arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the Secure attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The only Secure handling is on retrieval, where a Secure cookie is not sent over plaintext. So anyone who can answer a plaintext request to a site can set, replace or delete the site's Secure cookies, and the next HTTPS request carries the attacker's value back inside TLS: This does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie: A plaintext Set-Cookie of the same name, domain and path overwrites a Secure cookie, and one with Max-Age=0 deletes it. Depending…
Recommended action: Upgrade to 3.0.14; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact With WebSocket compression enabled, the client inflates permessage-deflate messages with no limit on the decompressed size. It installed Netty's shared WebSocketClientCompressionHandler.INSTANCE, whose inflater is unbounded, and webSocketMaxFrameSize and webSocketMaxBufferSize only bound the compressed bytes, because the frame aggregator sits in front of the inflater. A malicious or compromised WebSocket server, or anyone on the path of a ws:// connection, can therefore send a message of about 2 MiB that inflates to about 2 GiB, the most a Netty buffer can hold. The client then copies the inflated message again to hand it to the listener. That exhausts the heap of a typically sized JVM. Netty catches the resulting OutOfMemoryError and closes that connection, but while the buffer is live any other allocation in the process can fail too, and a server that keeps sending such messages, on one connection or several, keeps the client at heap exhaustion. Who is Impacted Only…
Recommended action: Upgrade to 3.0.14; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The fix for GHSA-vvp4-63h8-v5pm in 3.0.13 folded the authenticated principal into the HTTP/1.1 connection pool key, so that a connection one principal authenticated with NTLM, Kerberos or SPNEGO is not handed to another. It left three cases out. In each, a socket that one identity authenticated can still be drawn by a request belonging to a different identity, and the server serves that request as the first one. 1. A login with no configured principal. Kerberos and SPNEGO against the ticket cache or the default JAAS login, which is the usual deployment, leave the realm's principal unset, and the key stayed unscoped in that case. A request to the same host that carries no credentials at all draws the authenticated socket and is served as the service identity. 2. The proxy realm. Only the origin realm went into the key. A connection authenticated to a proxy with NTLM or Negotiate is handed to requests of another proxy identity, or of none, and the proxy acts for them as the…
Recommended action: Upgrade to 3.0.14; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The client nonce used in HTTP Digest authentication was generated from ThreadLocalRandom, a fast but non-cryptographic pseudorandom number generator. RFC 7616 section 3.3 requires the cnonce to be unpredictable, since it is part of what protects the Digest exchange against chosen-plaintext and precomputation attacks on the credentials. An attacker able to observe or influence enough of the generator's output could reduce the unpredictability the protocol depends on. NTLM (and, on the 3.x line, SCRAM) in this client already use SecureRandom for their own nonces; Digest did not. Affected versions 3.x: up to and including 3.0.11 2.x: up to and including 2.16.0 Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The cnonce is now generated with SecureRandom, matching the other authentication schemes in the client. Workarounds None available from application code. Details Realm.Builder's cnonce generation seeded its bytes from ThreadLocalRandom.current() rather…
Recommended action: Upgrade to 3.0.12 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a ws:// request is routed through an HTTP proxy with proxy authentication configured, the client tunnels the connection with an HTTP CONNECT, the same as it does for https://. Once the tunnel is open, the WebSocket upgrade request that follows is sent through the tunnel directly to the origin server, not to the proxy. The proxy-auth gate and the companion request-target selection keyed only on whether the URI was secured, which is false for ws://, so the tunnelled upgrade request incorrectly carried the proxy's Proxy-Authorization header and an absolute-form request target meant for the proxy. Any origin server reached over a proxied ws:// connection, or anyone positioned on the origin side of the wire, could recover the proxy credentials: directly for Basic, or as a replayable and offline-crackable response for Digest. Affected versions 3.x: up to and including 3.0.11 2.x: up to and including 2.16.0 Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line.…
Recommended action: Upgrade to 3.0.12 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The cookie store decides whether a Domain attribute may be accepted using only the domain-matching rule of RFC 6265 Section 5.1.3, which asks whether the request host is the domain or ends with a dot followed by it. Section 5.3 step 5, which additionally requires rejecting a Domain that is a public suffix, is not implemented anywhere in the client. So a host under a multi-label public suffix can set a cookie for the suffix itself, and the store then hands it to every other host under that suffix: Domain=uk works the same way. The attacker needs only a site under the same suffix as the victim, which for suffixes such as co.uk, com.au, or github.io is trivially obtainable. Depending on what the application does with the cookie, this is session fixation, or it overwrites a session the victim site set, or it lets the attacker plant a value the victim site trusts. Affected versions 3.x: up to and including 3.0.12 2.x: up to and including 2.16.0 Relationship to CVE-2026-55688…
Recommended action: Upgrade to 3.0.13 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a request is replayed onto a different host, the client updates only the current request and leaves the target request pointing at the original host. Four consumers read that stale value, and each one sends the first host's request, credentials, or both to the second host. A replay happens through documented, ordinary features: a ResponseFilter that returns a different request, which is the supported failover pattern, and the IOException retry path. The attacker does not need to induce the replay; an application that uses failover produces it by design. The socket to host B is filed in the connection pool under host A's key. A later request the application addresses to A is served over the connection to B, and A's Authorization header goes to B. Over a CONNECT tunnel, the client tunnels to B and negotiates TLS with B correctly, then writes A's request into that tunnel. B receives A's path, A's Host, and A's Authorization. TLS does not protect against this, because the…
Recommended action: Upgrade to 3.0.13 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A Digest challenge that does not yield a usable nonce is treated as a Basic challenge. The client then answers it with Authorization: Basic, which carries the username and password base64 encoded and so recoverable by anyone who sees the request. Any of these is enough, sent by whoever writes the 401 or 407: The challenge announces itself as Digest, so it passes the check that would otherwise reject a non-Digest challenge for a Digest realm. It then fails to produce a nonce, and the absence of a nonce is what selected Basic. A server offering plain Basic to a Digest realm gets nothing, so labelling the challenge Digest and leaving the nonce out is what makes the difference. This is reachable by anyone who can write the challenge: a malicious or compromised origin, a proxy, or an attacker on a plaintext hop. Digest exists precisely to keep the password off those hops. A server that stores only HA1, and anyone impersonating the real origin, does not otherwise learn the password…
Recommended action: Upgrade to 3.0.13 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A client configured with a client-wide realm (a Realm set on the config builder rather than on an individual request) and following redirects could re-send those credentials to a redirect target on a different origin. The redirect code strips the per-exchange realm, but when the target answered 401 the credentials were re-derived from the client config, handing Basic or Digest credentials, or a Negotiate or NTLM token, to an attacker controlled origin. This is a residual of the earlier cross-origin credential leak advisories, whose strip this bypassed. Affected versions 3.x: 3.0.9 through 3.0.11 2.x: 2.14.5 through 2.16.0 Releases below those floors are covered by the earlier advisories GHSA-cmxv-58fp-fm3g and GHSA-fmxf-pm6p-7xgm: the cross-origin strip that this issue bypasses did not exist yet, so the leak there is the original one rather than this residual. Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The realm is taken from the per-exchange state…
Recommended action: Upgrade to 3.0.12 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a request uses an HTTP proxy to reach an HTTPS origin, the client opens the tunnel with a plaintext CONNECT sent to the proxy before any TLS exists. On affected versions the origin's preemptive credentials were added to that CONNECT. A Basic realm sent Authorization: Basic base64(user:pass) to the proxy in the clear, and NTLM, SPNEGO or Kerberos realms sent their token. The proxy, and anyone who can read the client to proxy hop, saw credentials that were meant only for the origin. Affected versions 3.x: up to and including 3.0.11 2.x: up to and including 2.16.0 Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The origin Basic or Digest Authorization is no longer put on the CONNECT; it is added to the tunnelled request once the tunnel is up. The per-connection NTLM, Kerberos and SPNEGO token is likewise no longer attached on the tunnel path; it never reached the origin there in any case, and the challenge flow still negotiates it inside the tunnel.…
Recommended action: Upgrade to 3.0.12 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact With automatic response decompression enabled (the default), the HTTP/1.1 path decompresses response bodies with no limit on the total output size. A hostile or compromised server, or an attacker who can change a response in transit, can send a small compressed body that inflates without bound in memory, exhausting the client's heap and causing an OutOfMemoryError. gzip, deflate and snappy are always available as vectors; brotli and zstd apply only when those optional codecs are on the classpath. Affected versions 3.x: up to and including 3.0.11 2.x: up to and including 2.16.0 The HTTP/2 path carries its own limit from 3.0.11 onward. On 3.0.8, 3.0.9 and 3.0.10 the HTTP/2 decompressor is also unbounded, so on those versions switching to HTTP/2 is not a mitigation. Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The fix counts the decompressed bytes produced for each response and fails the response once the configured maximum is exceeded, so the limit…
Recommended action: Upgrade to 3.0.12 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact For SCRAM, and for Digest with mutual authentication, the client computes the server's verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value and the issue is inert; it matters over a non TLS transport, or when the transport is already compromised, where it removes the client's only signal that the peer does not know the secret. Affected versions 3.x: 3.0.8 through 3.0.11 Earlier 3.0.x releases are not affected: neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8. The 2.x line is not affected either: it has no SCRAM support, and its interceptor chain does not implement…
Recommended action: Upgrade to 3.0.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A cookie tossing / cookie injection issue (CWE-1275). ThreadSafeCookieStore stored a cookie under the value of its Domain attribute without verifying that the responding host is allowed to set a cookie for that domain (RFC 6265 §5.3 step 6). A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain. Who is Impacted Applications that use a single AsyncHttpClient instance - and thus the default, shared CookieStore - to reach both an attacker-influenced host and a trusted host. Typical exposure: crawlers, link-preview / webhook fetchers, SSRF-style "fetch this URL" features, multi-backend aggregators, or following redirects to an attacker-controlled host. The attacker can write a cookie the client presents to the victim host (session fixation, overwriting a session id / CSRF-token cookie); they cannot read the victim host's cookies. Applications that talk only to a fixed…
Recommended action: Upgrade to 3.0.11 or 2.16.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
async-http-client leaks Cookie headers to cross-origin redirect targets. When following a redirect across a security boundary (different origin, or HTTPS→HTTP downgrade), the propagatedHeaders() method in Redirect30xInterceptor.java strips Authorization and Proxy-Authorization headers but does not strip Cookie, so session cookies and other sensitive cookie values are forwarded to the redirect target — which may be attacker-controlled. Details The vulnerability is in client/src/main/java/org/asynchttpclient/netty/handler/intercept/Redirect30xInterceptor.java. The caller computes stripAuth on each redirect: stripAuth is true whenever the redirect crosses an origin, downgrades the scheme, or the caller opted in via AsyncHttpClientConfig#isStripAuthorizationOnRedirect(). In the vulnerable version, propagatedHeaders() only removes Authorization and Proxy-Authorization in that branch — Cookie is left untouched: The companion test class RedirectCredentialSecurityTest covers…
Recommended action: Upgrade to 3.0.10 or 2.15.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When redirect following is enabled (followRedirect(true)), AsyncHttpClient forwards Authorization and Proxy-Authorization headers along with Realm credentials to arbitrary redirect targets regardless of domain, scheme, or port changes. This leaks credentials on cross-domain redirects and HTTPS-to-HTTP downgrades. Additionally, even when stripAuthorizationOnRedirect is set to true, the Realm object containing plaintext credentials is still propagated to the redirect request, causing credential re-generation for Basic and Digest authentication schemes via NettyRequestFactory. An attacker who controls a redirect target (via open redirect, DNS rebinding, or MITM on HTTP) can capture Bearer tokens, Basic auth credentials, or any other Authorization header value. Patches Fixed in version 3.0.9 or 2.14.5. Users should upgrade immediately. The fix automatically strips Authorization and Proxy-Authorization headers and clears Realm credentials whenever a redirect crosses origin…
Recommended action: Upgrade to 3.0.9 or 2.14.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When making any HTTP request, the automatically enabled and self-managed CookieStore (aka cookie jar) will silently replace explicitly defined Cookies with any that have the same name from the cookie jar. For services that operate with multiple users, this can result in one user's Cookie being used for another user's requests. Details This issue is described without security warnings here: https://github.com/AsyncHttpClient/async-http-client/issues/1964 A PR to fix this issue has been made: https://github.com/AsyncHttpClient/async-http-client/pull/2033 PoC 1. Add an auth Cookie to the CookieStore - This is identical to receiving an HTTP response that uses Set-Cookie, as shown in issue #1964 above. 2. Handle a different user's request where the same Cookie is provided as a passthrough, like a JWT, and attempt to use it by explicitly providing it. 3. Observe that the user's cookie in step 2 is passed as the Cookie in step 1. Impact This is generally going to be a problem for…
Recommended action: Upgrade to 3.0.1 or 2.12.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Similar bugs were previously identified in cURL (CVE-2016-8624) and Oracle Java 8 java.net.URL.
Recommended action: Upgrade to 2.0.35 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.