GHSA-f9m8-cv68-674w

Dashboard / Vulnerabilities / GHSA-f9m8-cv68-674w

GHSA-f9m8-cv68-674w

Summary: AsyncHttpClient: Cookie Domain attribute is not checked against the public suffix list, so a cookie can be set for co.uk

Details: ### Impact The cookie store decides whether a `Domain` attribute may be accepted using only the domain-matching rule of RFC 6265 Section 5.1.3, which asks whether the request host is the domain or ends with a dot followed by it. Section 5.3 step 5, which additionally requires rejecting a `Domain` that is a public suffix, is not implemented anywhere in the client. So a host under a multi-label public suffix can set a cookie for the suffix itself, and the store then hands it to every other host under that suffix: ``` attacker.co.uk -> Set-Cookie: SID=attacker-value; Domain=co.uk; Path=/ bank.co.uk -> Cookie: SID=attacker-value ``` `Domain=uk` works the same way. The attacker needs only a site under the same suffix as the victim, which for suffixes such as `co.uk`, `com.au`, or `github.io` is trivially obtainable. Depending on what the application does with the cookie, this is session fixation, or it overwrites a session the victim site set, or it lets the attacker plant a value the victim site trusts. ### Affected versions * 3.x: up to and including 3.0.12 * 2.x: up to and including 2.16.0 ### Relationship to CVE-2026-55688 CVE-2026-55688 (GHSA-m452-q8c9-rg2f) covered the direct form of this, where a host sets a `Domain` naming an unrelated host, and that form is genuinely fixed: `attacker.co.uk` can no longer set `Domain=bank.co.uk`, and this was verified as a control. What that fix did not add is the public suffix test, so setting `Domain=co.uk` still reaches `bank.co.uk`. This advisory covers only the residual. ### Patches Fixed in 3.0.13 on the 3.x line. The ICANN section of the Mozilla public suffix list is bundled with the client and a `Domain` matching it is rejected, honouring the list's wildcard and exception rules. The list is data and goes stale, so a suffix added upstream after a release is not recognised until the bundled copy is refreshed. The 2.x line is not yet fixed. ### Workarounds Do not share one `CookieStore` across origins that are not mutually trusted. Supplying a `CookieStore` implementation that rejects `Domain` values which are public suffixes also avoids it. ### Details `ThreadSafeCookieStore.domainsMatch` is `requestDomain.equals(cookieDomain) || requestDomain.endsWith('.' + cookieDomain)`. It is used both to accept a `Domain` on storage and to select cookies for a request, and neither call site consults a public suffix list. A search of the client for any public suffix or effective TLD handling returns nothing.

References: https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-f9m8-cv68-674w, https://nvd.nist.gov/vuln/detail/CVE-2026-107280, https://github.com/AsyncHttpClient/async-http-client/commit/330267895fe0bdb41bbd027ea6b151d38ee7c23d, https://github.com/AsyncHttpClient/async-http-client/commit/d1f0ccec417092098d40242fee7dfac84bb3c21f, https://github.com/AsyncHttpClient/async-http-client, https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-2.16.1, https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-3.0.13