AsyncHttpClient EUVD-2026-94640

Exploitation requires the application to configure AsyncHttpClient with a connection-oriented, connection-authenticating scheme - NTLM, Kerberos, or SPNEGO/Negotiate (a Realm using AuthScheme.NTLM/KERBEROS/SPNEGO) - over HTTP/1.1 with keep-alive connection pooling enabled (default), AND to reuse the same client/connection pool across requests carrying different authenticated principals (e.g. a multi-user gateway or proxy). The flaw is the HTTP/1.1 pool key omitting the authenticated principal, so a socket authenticated for one identity can be reused by another. Basic and Digest configurations are explicitly NOT affected because they authenticate every request. Limiting factors: the attacker must be an authenticated principal (PR:L); a suitable already-authenticated pooled socket must exist at the right moment (AT:P, AC:H timing dependency); single-principal deployments and non-NTLM/Negotiate setups are not exploitable.

The source-provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N, 7.6 High) is internally consistent with the description: AV:N (the client talks to a network backend), AC:H plus AT:P capture that exploitation is non-deterministic and conditional (a pooled, already-authenticated socket must exist and be handed to a differently-authenticated request - a timing/state-dependent race), PR:L reflects that the actor must be a legitimate principal already using the application, and VC:H/VI:H reflect full impersonation (reading and acting as another identity). No EPSS score, no CISA KEV listing, and no POC were provided in the intelligence set, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The high confidentiality/integrity impact is tempered by genuinely narrow preconditions: the application must use connection-oriented NTLM, Kerberos, or SPNEGO/Negotiate authentication AND share one AHC connection pool across multiple distinct principals. This is a real but conditional priority - not a widely-sprayable internet-facing flaw. Treat it as high priority specifically for multi-tenant or multi-user Java services that front a backend with NTLM/Negotiate via AHC, and as low practical risk for the (common) deployments using Basic/Digest or a single principal, which are unaffected.

A Java application uses a single shared AsyncHttpClient instance with connection-oriented NTLM or Negotiate authentication to call a backend on behalf of many users. A keep-alive socket authenticated as principal B remains pooled; principal A's subsequent request is drawn from the pool onto that socket, and because the second request carries no auth headers of its own, the backend executes A's request as B - exposing B's data or performing actions under B's identity. No public exploit identified at time of analysis; exploitation is opportunistic and timing-dependent given AC:H/AT:P.