CVE-2026-82209

libcurl builds with libpsl support fail to enforce the Public Suffix List boundary check when a server whose hostname is itself a public suffix (e.g., co.uk) sends a Set-Cookie with an explicit Domain attribute (e.g., Domain=co.uk). Instead of coercing the cookie to host-only scope, libcurl saves it as a wildcard-domain cookie (.co.uk), so it is replayed on subsequent requests and redirects to arbitrary sibling subdomains such as attacker.co.uk. An attacker who can induce a libcurl-based client to connect to such an origin and controls a sibling subdomain under the same public suffix can capture cookies intended only for the original host, potentially exposing session tokens or credentials (CVSS 3.1: 8.2, high integrity impact). Any application embedding libcurl in a build with libpsl enabled is affected; the data does not specify affected version ranges. Exploitation has not been observed: there is no public PoC, it is not in CISA KEV, and EPSS estimates only a ~0.4% chance of exploitation within 30 days.

What to do: Track the curl project and your OS vendor for a patched libcurl release and update as soon as available, since the data does not identify specific fixed versions. Verify whether your libcurl build has libpsl enabled (e.g., 'curl --version' or 'curl-config --configure') and, as an interim mitigation, avoid persistent cookie jars when connecting to hosts whose hostnames are themselves public suffixes, or re-enable strict PSL handling per your vendor's guidance. Check whether any of your workloads accept cookies from or interact with domains directly on public suffixes, where sibling-subdomain leakage would be exploitable.