CVE-2026-107228: AsyncHttpClient CookieStore Silently Overrides Caller's Explicit Cookie Header via setHeader (Bypass of CVE-2024-53990 Fix)
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.1.0 until 3.0.14, the enabled-by-default cookie store replaces a Cookie header explicitly supplied through setHeader or addHeader whenever the store contributes any cookie for the origin. In a shared client, stored cookies originating from one user can replace a different user's request cookie, causing the request to execute under the wrong session. This bypasses the earlier CVE-2024-53990 remediation, which covered cookies supplied through addCookie but not a directly supplied header. In the affected execution path, setHeader, addHeader, Cookie header, and CookieStore control or expose the vulnerable behavior. This issue is fixed in version 3.0.14.
Other sources
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.1.0 until 3.0.14, the enabled-by-default cookie store replaces a Cookie header explicitly supplied through setHeader or addHeader whenever the store contributes any cookie for the origin. In a shared client, stored cookies originating from one user can replace a different user's request cookie, causing the request to execute under the wrong session. This bypasses the earlier CVE-2024-53990 remediation, which covered cookies supplied through addCookie but not a directly supplied header. This issue is fixed in version 3.0.14.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
AsyncHttpClientto a version that resolves this vulnerability.Fixed in 3.0.14
Event History
Frequently Asked Questions
Which applications are realistically exposed to cross-user session confusion?
Applications using AsyncHttpClient versions 2.1.0 through before 3.0.14 are exposed when they share a client with its default-enabled cookie store across users or sessions, and send explicit Cookie headers using setHeader or addHeader. A stored cookie for the target origin can then replace the caller-supplied cookie.
Does this affect the default configuration?
Yes. The cookie store is enabled by default, so applications do not need to explicitly enable it to encounter the issue. Exploitation also requires the cookie store to contribute at least one cookie for the request origin.
What should teams do if they cannot immediately upgrade?
Avoid sharing an AsyncHttpClient instance and its cookie store between different users or sessions. Where possible, prevent stored cookies from being used for requests that supply an explicit Cookie header.
How can teams identify potentially affected code paths?
Review AsyncHttpClient usage for shared clients on versions 2.1.0 through before 3.0.14, especially requests that set a Cookie header through setHeader or addHeader. Prioritize paths where the same client may retain cookies from one user while sending requests on behalf of another.