async-http-client Cookie Domain Public Suffix Bypass (CVE-2026-107280)

Vulnerability Overview Vulnerability Name: Cookie Domain attribute is not checked against the public suffix list, so a cookie can be set for co.uk CVE ID: CVE-2026-107280 Severity: Moderate Release Date: Aug 10 Author: hyperxpro Impact When determining whether to accept the attribute, Cookie storage relies solely on the domain matching rules in RFC 6265 Section 5.1.3, which asks if the request host is the domain or ends with a dot followed by the domain. Section 5.3, step 5, additionally requires rejecting cases where the is a public suffix, but this requirement is not implemented in the code. Therefore, hosts under multi-label public suffixes can set cookies for the suffix itself, and storage will pass them to every host under that suffix. Example Code works the same way. An attacker only needs a site under the same suffix as the victim, such as , , or , which is easy to obtain. Version 3.0.13 does not cover and other suffixes in the private section; see GHSA-qq7-w8gj-pmrv. Depending on how the application handles cookies, this could result in session fixation, overwriting session cookies set by the victim's site, or allowing an attacker to implant values in the victim's site. Affected Versions 3.x: Up to and including 3.0.12 2.x: Up to and including 2.16.0 Relation to CVE-2026-55688 CVE-2026-55688 (GHSA-m452-qkc9-rp2f) covers the direct form of this issue, where a host sets a cookie with a for an unrelated host, and this form has been truly fixed: can no longer set , and this is verified as controlled. What was not added in the fix is the public suffix test, so setting can still reach . This advisory covers only the remaining part. Resolution The fix was made in the 3.x branch for version 3.0.13. The Mozilla Public Suffix List ICANN section is bundled with the client and enforces domain matching. The list is data and becomes stale, so suffixes added after release are not recognized until the bundled list is refreshed. The 2.x branch is fixed starting from 2.16.1. Workaround Do not share the same between untrusted sources. Provide a implementation that rejects public suffixes. Details Known Limitations of Fix in 3.0.13 There are two issues that still exist in 3.0.13, so 3.0.13 is no worse than 3.0.12, but both are closed: Top-level domains appear in the list only as wildcard rules, without their own rules: , , , , , , , . The list specification algorithm ends by applying the default rule when no other match is found, and this step is not implemented, so a naming one of these is accepted. Under , a host can still set a cookie for . The check itself is locale-independent, but the cookie storage lowercases the request host and the attribute using the default locale when called. In cases where local storage has lowercase differences, such as ASCII and Turkish, uppercase hosts and bypass the check. Both are fixed in 3.0.14, along with further vulnerabilities in GHSA-qq7-w8gj-pmrv. The 2.x branch is at the end of its lifecycle, so 2.16.1 retains them.

Goal Reached Thanks to every supporter — we hit 100%!

async-http-client Cookie Domain Public Suffix Bypass (CVE-2026-107280)

More from this source