AsyncHttpClient EUVD-2026-94589

Requires a shared AsyncHttpClient instance (versions 2.1.0 through before 3.0.14) serving multiple users/sessions with the enabled-by-default CookieStore left active, AND at least one user supplying cookies directly through a Cookie header via setHeader or addHeader (not addCookie). The store must already hold a cookie for the same origin, contributed by a different user, for the replacement to occur. Limiting factors: the attacker must be an authenticated participant on the shared client (PR:L); single-user or per-request client instances, or deployments that disable the cookie store, are not affected; exploitation also depends on timing/ordering of stored cookies for the origin (AC:H), so it is not deterministically triggerable on demand.

This is a genuine but conditional multi-tenancy flaw (CWE-287) rather than a broadly weaponizable remote exploit. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N = 6.8 Medium) is internally consistent with the description: AC:H reflects that exploitation depends on the enabled-by-default CookieStore actually contributing a cookie for the origin and on request timing within a shared client, and PR:L reflects that the attacker must be a legitimate authenticated user whose cookies get stored. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so by the precision rules this is 'no public exploit identified at time of analysis' - exploitation is plausible by an insider/co-tenant but not demonstrated in the wild. The signals do not conflict: a Medium CVSS, absent KEV, and absent POC all point to a real-but-not-urgent issue whose impact (one user's request executing under another user's session, i.e. session confusion) is high per-incident but gated by a specific architecture (a shared AHC client serving multiple users with the cookie store left enabled). Note this explicitly bypasses the earlier CVE-2024-53990 fix, which only covered addCookie and not directly-set Cookie headers, so environments that believed they were patched against the prior CVE remain exposed via setHeader/addHeader.

A Java service uses a single shared AsyncHttpClient instance (with the default cookie store enabled) to proxy or relay requests on behalf of many end users. User A sends a request with an explicit Cookie header via setHeader/addHeader, but the store injects cookies previously captured from User B for the same origin, replacing A's header so the upstream request runs under B's session. No public PoC is referenced; exploitation requires an attacker to be one of the authenticated users sharing that client instance.