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:

WWW-Authenticate: Digest realm="protected" WWW-Authenticate: Digest realm="protected", nonce=""

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 itself, so the disclosure enables reuse against other services.

Both the target and the proxy paths are affected, through parseWWWAuthenticateHeader and parseProxyAuthenticateHeader.

Affected versions 3.x: up to and including 3.0.12 2.x: up to and including 2.16.0

This is long-standing behaviour on both lines, not a recent regression. On 3.0.12 there is one additional way to reach it: a quoted parameter ending in an unescaped backslash, such as realm="C:\", makes the closing quote read as escaped so the nonce is never found. That trigger is specific to 3.0.12. The downgrade it led to is fixed, but the nonce is still lost on such a challenge: every conformant reader treats the closing quote as escaped. The exchange now fails instead of falling back to Basic.

Patches Fixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The scheme now comes from the challenge itself instead of being inferred from whether a nonce was found, so a Digest challenge stays Digest even when it cannot be read. With no nonce it produces no Authorization header at all, which fails the exchange rather than downgrading it.

The 3.x fix also corrects quoted-pair handling so that a backslash before any character other than a quote or another backslash is kept as written, matching Apache HttpComponents. That repairs a 3.0.12 regression where an unescaped realm such as DOMAIN\Users was corrupted to DOMAINUsers and failed every digest comparison. This is a deliberate deviation from a strict reading of RFC 9110 Section 5.6.4, under which a backslash before any character is a quoted-pair. Reading it strictly is what corrupts the unescaped spelling that servers actually send, and the decoding is not reversible either way, so the client follows the same rule as Apache HttpComponents.

Workarounds No configuration prevents this. Until you can upgrade, do not use Digest authentication against a server you do not control, and do not use it over plaintext HTTP.

Details Realm.Builder.parseWWWAuthenticateHeader and parseProxyAuthenticateHeader selected the scheme with isNonEmpty(nonce) ? AuthScheme.DIGEST : AuthScheme.BASIC, so any challenge that produced no nonce became a Basic challenge and Unauthorized401Interceptor resent the request using computeBasicAuthentication.

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.

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:

attacker.co.uk -> Set-Cookie: SID=attacker-value; Domain=co.uk; Path=/ bank.co.uk -> Cookie: SID=attacker-value

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 CVE-2026-55688 (GHSA-m452-q8c9-rg2f) covered the direct form of this, where a host sets a Domain naming an unrelated host, and that form is genuinely fixed: attacker.co.uk can no longer set Domain=bank.co.uk, and this was verified as a control. What that fix did not add is the public suffix test, so setting Domain=co.uk still reaches bank.co.uk. This advisory covers only the residual.

Patches Fixed in 3.0.13 on the 3.x line. The ICANN section of the Mozilla public suffix list is bundled with the client and a Domain matching it is rejected, honouring the list's wildcard and exception rules. The list is data and goes stale, so a suffix added upstream after a release is not recognised until the bundled copy is refreshed. The 2.x line is not yet fixed.

Workarounds Do not share one CookieStore across origins that are not mutually trusted. Supplying a CookieStore implementation that rejects Domain values which are public suffixes also avoids it.

Details ThreadSafeCookieStore.domainsMatch is requestDomain.equals(cookieDomain) || requestDomain.endsWith('.' + cookieDomain). It is used both to accept a Domain on storage and to select cookies for a request, and neither call site consults a public suffix list. A search of the client for any public suffix or effective TLD handling returns nothing.

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 to another user. The request runs as that other user, so a user of such an application can have their request served under someone else's session, or someone else's under theirs.

Affected versions

3.x: up to and including 3.0.13 2.x: from 2.1.0 up to and including 2.16.1

Patches

Fixed in 3.0.14. The store's cookies are added to a caller's Cookie header instead of replacing it, and where both name the same cookie the caller's is kept. The caller's text is kept as written, and several Cookie headers are folded into one, as RFC 6265 Section 5.4 requires.

The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.

Workarounds

Where requests carry per-user cookies, use a separate client per user, or disable the cookie store with setCookieStore(null).

References

Incomplete fix of CVE-2024-53990 (GHSA-mfj5-cf8g-g2fv). Reported by @1diot9.

Attribution

AI-assisted tools were used to support discovery and analysis.

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. The preemptive Proxy-Authorization header and the absolute-form request target are no longer attached to a tunnelled ws:// upgrade; a ws:// request is now treated like wss://.

Workarounds Do not use proxy authentication together with ws:// requests through an HTTP proxy, or use wss:// instead.

Details The proxy-auth gate in NettyRequestFactory#newNettyRequest and the sibling branch in requestUri() did not exclude WebSocket URIs, even though the CONNECT-tunnelling check in NettyRequestSender already tunnels ws:// through CONNECT exactly like https://.

Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.

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 than a SecureRandom instance.