GHSA-2jwh-9rmr-j4xf: Medium severity maven/org.asynchttpclient:async-http-client vulnerability
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.
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 to a fixed release to a version that resolves this vulnerability.
Fixed in 3.0.14 - Configuration
Disable the cookie store with setCookieStore(null) where requests carry per-user cookies.
cookie store setCookieStore = null - Compensating control
Where requests carry per-user cookies, use a separate client per user.
Event History
Frequently Asked Questions
Is the default configuration affected?
Yes. The cookie store is enabled by default, and the issue occurs when a caller sets a Cookie header directly with setHeader or addHeader while the store contains any cookie for that request origin.
Which applications are most exposed to cross-user impact?
Applications that share one client and its default cookie store across multiple users are most exposed, particularly when each user's session cookie is attached directly to individual requests. A cookie learned from one user's response can replace the session cookie intended for another user's request.
Does this require a stored cookie with the same name as the caller's session cookie?
No. Any cookie in the store for the request origin can cause the directly supplied Cookie header to be discarded. If the store has a cookie with the same name, its value is sent instead.
How can I identify potentially affected usage?
Review code for requests that set Cookie directly through setHeader or addHeader, especially where the same client instance or default cookie store is used for more than one user. The risk is present when that store can retain cookies received from responses for the same origin.
Does the earlier fix for cookies added with addCookie address this case?
No. The earlier fix applies to cookies added through addCookie, while a Cookie header set directly does not reach the cookie list used by that fix.