CVE-2026-107228: AsyncHttpClient CookieStore Silently Overrides Caller's Explicit Cookie Header via setHeader (Bypass of CVE-2024-53990 Fix)
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.
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
maven/org.asynchttpclient:async-http-clientto a version that resolves this vulnerability.Fixed in 3.0.14 - Upgrade
Upgrade
AsyncHttpClient (AHC)to a version that resolves this vulnerability.Fixed in 3.0.14 - Configuration
Disable the cookie store for requests carrying per-user cookies by calling setCookieStore(null).
AsyncHttpClient cookie store = null - Compensating control
Where requests carry per-user cookies, use a separate client per user.
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.