CVE-2026-69214 in Http4s
Summary
by MITRE • 09/15/2026
Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The CookieJar client middleware stores a response cookie’s Domain attribute without checking that it domain-matches the host that supplied the cookie or rejecting public suffixes. A malicious or compromised server contacted through the same CookieJar can plant a cookie for another domain, and the jar later sends that cookie to the victim domain, enabling session fixation or overwriting security-sensitive cookies. The patch validates the Set-Cookie domain against the response origin, although public-suffix rejection remains unimplemented. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
Http4s serves as a prominent functional HTTP client and server library for the Scala programming language, widely adopted in enterprise environments for building robust web services. Within this ecosystem, the CookieJar middleware plays a critical role in managing stateful interactions by automatically storing cookies from responses and attaching them to subsequent requests based on domain rules defined in RFC 6265. A significant security flaw existed in versions prior to 0.23.35 and 1.0.0-M47, where the implementation failed to strictly validate the Domain attribute of Set-Cookie headers against the origin server that issued them. This oversight allowed for a class of attacks known as cookie poisoning or cross-domain cookie injection, fundamentally undermining the isolation guarantees expected from browser-like cookie storage mechanisms in non-browser contexts.
The technical root cause lies in the absence of domain-matching logic and public suffix list validation during the parsing of Set-Cookie headers. According to standard HTTP practices, a server should only be able to set cookies for its own domain or subdomains thereof. However, the vulnerable implementation accepted any Domain attribute provided by the response without verifying that it matched the host contacted. Consequently, if an attacker controlled a malicious server or compromised a legitimate one, they could instruct the CookieJar middleware to store a cookie with a Domain attribute pointing to a completely different target organization. For instance, a request to evil.com could result in the storage of a cookie intended for bank.com, provided the response header explicitly specified that domain.
This vulnerability enables severe operational impacts, primarily session fixation and the overwriting of security-sensitive cookies such as those carrying authentication tokens or anti-CSRF values. When the CookieJar middleware later processes requests directed at the victim domain, it erroneously includes the maliciously planted cookie because its internal store associates the cookie with that target domain based on the attacker-supplied metadata rather than the actual request context. This allows an adversary to inject arbitrary session identifiers into a user's active sessions or overwrite critical security tokens, potentially leading to unauthorized access, privilege escalation, or complete account takeover without requiring traditional cross-site scripting vectors.
The remediation introduced in versions 0.23.35 and 1.0.0-M47 addresses the primary vector by enforcing strict validation of the Set-Cookie Domain attribute against the response origin. The updated logic ensures that cookies are only stored if their domain matches or is a subdomain of the host that issued them, thereby preventing cross-domain cookie planting. It is important to note that while this patch resolves the immediate injection risk, it does not yet implement rejection based on public suffix lists as recommended by RFC 6265 Section 5.3. This means that theoretically, if an attacker controls a domain like co.uk or com, they might still attempt to set cookies for broader top-level domains depending on specific implementation details of the matching logic, although this is less common and often mitigated by browser security policies not present in all server-side libraries.
From a classification perspective, this vulnerability aligns with CWE-16, which covers configuration issues related to trust boundaries, specifically involving improper handling of input from external sources that affects system state. In the context of the MITRE ATT&CK framework, this behavior facilitates Initial Access and Persistence techniques by allowing attackers to manipulate session states remotely without direct interaction with the application's primary logic flow. Organizations utilizing Http4s must upgrade immediately to mitigate these risks. Additionally, developers should remain vigilant regarding public suffix handling in future updates and consider implementing additional validation layers if their threat model includes sophisticated adversaries capable of controlling high-level domain registrations.