AsyncHttpClient EUVD-2026-94635

Requires the AHC connection pool to contain a reusable keep-alive socket whose authentication state is not reflected in the pool partition key. Concretely, the application must use one of: Kerberos, SPNEGO, NTLM, an authenticated proxy (proxy realm), or SOCKS/CONNECT proxy logins - and specifically the identity-ambiguous cases named in the advisory: logins without a configured principal, proxy realms, distinct identities sharing the same user name, and SOCKS/CONNECT proxy logins. LIMITING FACTORS: applications using only HTTP Basic/Digest, or a single identity/principal, are not affected; exploitation also depends on timing the reuse of an already-authenticated socket (AC:H) and on the application multiplexing multiple callers/identities over one AHC client instance. Default single-identity usage and non-GSS/non-proxy auth are not exploitable.

This is a credible but conditional information-disclosure/authentication-bypass issue (CWE-346, Origin Validation Error), not a mass-exploitation emergency. The CVSS 3.1 base score is 7.4 (High) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N: network reachable and requiring no privileges, but with high attack complexity (AC:H) because exploitation depends on a specific pooled-connection reuse race and non-default authentication configurations. No EPSS score was supplied in the input, and the CVE is NOT present in CISA KEV, so there is no evidence of active exploitation. No public exploit code was provided - only the vendor security advisory, the fixing commit, and the 3.0.14 release are referenced. The practical risk is therefore moderate and targeted rather than broad: the flaw only matters to Java applications that use AHC with Kerberos, SPNEGO, NTLM, or authenticated SOCKS/CONNECT proxies AND multiplex more than one identity (or anonymous plus authenticated callers) over a shared connection pool. One signal tension worth flagging: the CVSS marks PR:N (unauthenticated), yet the real attacker is typically a co-tenant/legitimate caller of the same AHC-backed application who opportunistically reuses a socket authenticated as another identity - PR:N is defensible because the reusing request itself presents no credentials, but defenders should read this as a cross-identity leak within a shared application, not a classic external-attacker RCE. Prioritize patching for multi-tenant gateways/proxies and SSO-integrated services; deprioritize for apps that use only Basic/Digest or a single identity.

A multi-tenant Java service uses AsyncHttpClient with Kerberos/SPNEGO (or an authenticated CONNECT/SOCKS proxy) to make outbound requests on behalf of different users. Because the connection-pool key omits the identity, a request for user B is dispatched over a keep-alive socket that was already authenticated as user A, causing B's call to execute with A's identity and return or act on A's data and authority. No public proof-of-concept was provided; exploitation hinges on timing the pool reuse (AC:H) under a vulnerable auth configuration.