GHSA-f9m8-cv68-674w AsyncHttpClient: Cookie Domain attribute is not checked against the public suffix list, so a cookie can be set for co.uk

• Maven org.asynchttpclient:async-http-client: >= 3.0.0, < 3.0.13 → fixed in 3.0.13 • Maven org.asynchttpclient:async-http-client: >= 2.0.0, < 2.16.1 → fixed in 2.16.1

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.