CVE-2026-69214: Session Fixation via Arbitrary Set-Cookie Domain Acceptance in http4s CookieJar Middleware

The http4s library provides minimal, idiomatic Scala interfaces for HTTP services, including client-side middleware utilities. One such utility is the CookieJar client middleware, which allows applications to programmatically maintain and manage HTTP cookies across sequential HTTP requests.

Prior to the security fixes implemented in versions 0.23.35 and 1.0.0-M47, the CookieJar middleware failed to perform proper domain matching checks when processing the Set-Cookie header in HTTP responses. According to security specifications, client agents must prevent servers from setting cookies for domains outside of their immediate authority (e.g., attacker.com setting a cookie for targetbank.com).

Because the middleware unconditionally accepted the server-provided Domain attribute, any system using a shared CookieJar instance to access multi-tenant environments, web scraping endpoints, or proxy destinations was vulnerable to cookie injection. Attackers could plant custom session states or bypass integrity protection on critical target domains.

The vulnerability stems from a violation of RFC 6265 Section 5.3 Step 6. Under this specification, a client user-agent must reject cookie Domain attributes that do not domain-match the origin host that supplied the cookie. The purpose of this check is to prevent hostile servers from registering cookies targeting arbitrary scopes.

In the vulnerable http4s implementation, the extractFromResponseCookie function parsed incoming response cookies and registered them using the following logic:

c.domain.orElse(uri.host.map(_.value)) match {
  case Some(domainS) =>
    val key = CookieKey(c.name, domainS, c.path)
    val newCookie = c.copy(domain = domainS.some)
    m + (key -> CookieValue(newCookie, httpDate))
}

If the cookie parsed from the response (c.domain) contained a custom Domain attribute, the code assigned it directly as the storage key's domain (domainS), skipping any validation against the actual origin host (uri.host). Consequently, an HTTP client querying multiple destinations could have its state polluted by a single compromised or malicious server.

The vulnerability was mitigated in commit 87535f7288f3baaf6736e2735087e473762b5b2f by validating the parsed cookie domain against the origin host prior to storage.

// Patched logic in CookieJar.scala
private[middleware] def extractFromResponseCookie(
    m: Map[CookieKey, CookieValue]
)(c: ResponseCookie, httpDate: HttpDate, uri: Uri): Map[CookieKey, CookieValue] = {
  val storedDomain = c.domain match {
    case Some(d) =>
      // Confirm that the response host exists and domain-matches the attribute
      if (uri.host.exists(domainMatches(_, d))) Some(d) else None
    case None =>
      uri.host.map(_.value)
  }
  storedDomain match {
    case Some(domainS) =>
      val key = CookieKey(c.name, domainS, c.path)
      val newCookie = c.copy(domain = domainS.some)
      m + (key -> CookieValue(newCookie, httpDate))
    case None => // Ignore Cookies We Can't get a domain for
      m
  }
}

The patched version checks if the target domain (d) matches the host using domainMatches. If the domain is not authoritative for the current origin host, it is set to None, which safely discards the unauthorized cookie registration.

Despite this fix, a key security limitation remains. The library does not implement Public Suffix List (PSL) validation. Therefore, a server hosted on a shared public suffix (such as victim.github.io) is still technically capable of planting a cookie for the entire public suffix wildcard (github.io). Multi-tenant application designs must remain cautious when sharing a single CookieJar context across tenant boundaries.

To execute this attack, the client must use a single CookieJar instance to send requests to both the attacker-controlled server and the victim domain. This is common in automation platforms, crawlers, or services routing traffic for multiple users.

First, the attacker provisions a session identifier (attacker_id) on the target web application (target.com). Next, when the victim's client makes an outbound connection to attacker.com, the attacker's server responds with an unauthorized cookie instruction specifying the target domain:

HTTP/1.1 200 OK
Set-Cookie: session=attacker_id; Domain=target.com; Path=/; Secure; HttpOnly

Because the vulnerable client registers this cookie without validating the origin, the local cookie jar maps session=attacker_id under target.com. When the client subsequently requests resource paths on target.com, the client transmits the injected cookie, completing the session fixation vector.

To resolve this security issue, software developers must update their project dependencies to the appropriate patched releases. The official fixes have been backported to standard release lines.

For systems utilizing the 0.23.x release series, update the dependency to 0.23.35:

libraryDependencies += "org.http4s" %% "http4s-client" % "0.23.35"

For systems utilizing the 1.0.x pre-release series, update the dependency to 1.0.0-M47:

libraryDependencies += "org.http4s" %% "http4s-client" % "1.0.0-M47"

If upgrading dependencies is not immediately feasible, developers must isolate CookieJar instances. Avoid sharing a single client context across requests to different administrative domains. Instantiating distinct client instances or unique cookie jars per remote target host isolates states and prevents cross-origin data pollution.