GHSA-2JWH-9RMR-J4XF
Vulnerability from github – Published: 2026-10-08 16:50 – Updated: 2026-10-08 16:50Impact
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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.13"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"last_affected": "2.16.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107228"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T16:50:03Z",
"nvd_published_at": "2026-10-07T21:17:14Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWith 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\u0027s origin: the request\u0027s 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.\n\nThis is not limited to a cookie of the same name. A store cookie of any name erases the caller\u0027s header, so a request meant to carry the caller\u0027s session cookie goes out with only the store\u0027s cookies, and where the store has a cookie of the caller\u0027s name, the store\u0027s value is sent instead.\n\nIt matters most where one client acts for several users. An application that puts each user\u0027s session on the request itself, and shares one client and its default cookie store, sends one user\u0027s 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\u0027s session, or someone else\u0027s under theirs.\n\n### Affected versions\n\n* 3.x: up to and including 3.0.13\n* 2.x: from 2.1.0 up to and including 2.16.1\n\n### Patches\n\nFixed in 3.0.14. The store\u0027s cookies are added to a caller\u0027s `Cookie` header instead of replacing it, and where both name the same cookie the caller\u0027s is kept. The caller\u0027s text is kept as written, and several `Cookie` headers are folded into one, as RFC 6265 Section 5.4 requires.\n\nThe 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.\n\n### Workarounds\n\nWhere requests carry per-user cookies, use a separate client per user, or disable the cookie store with `setCookieStore(null)`.\n\n### References\n\nIncomplete fix of CVE-2024-53990 (GHSA-mfj5-cf8g-g2fv). Reported by @1diot9.\n\n### Attribution\n\nAI-assisted tools were used to support discovery and analysis.",
"id": "GHSA-2jwh-9rmr-j4xf",
"modified": "2026-10-08T16:50:03Z",
"published": "2026-10-08T16:50:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-2jwh-9rmr-j4xf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107228"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/fd9763620725126c1c8bb0af1ceb9a7523099a5f"
},
{
"type": "PACKAGE",
"url": "https://github.com/AsyncHttpClient/async-http-client"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-3.0.14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "AsyncHttpClient CookieStore Silently Overrides Caller\u0027s Explicit Cookie Header via setHeader (Bypass of CVE-2024-53990 Fix)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.