CVE-2026-69211 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, ResponseCookie.render writes attacker-influenced name, content, domain, path, and extension values without neutralizing semicolons or control characters. An application that constructs a ResponseCookie from unvalidated input can therefore emit injected cookie attributes such as Domain, Path, or SameSite, widening cookie scope or weakening protections, and control characters may enable header splitting on permissive backends. The patch strips control characters from all five fields and strips semicolons from name, content, domain, and path while retaining the extension delimiter behavior. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
Http4s serves as a prominent functional HTTP library for Scala applications, providing robust abstractions for building web services. A critical security flaw was identified within the ResponseCookie rendering logic in versions prior to 0.23.35 and 1.0.0-M47. The vulnerability stems from insufficient input validation when constructing cookie attributes such as name, content, domain, path, and extension. Specifically, these fields were written directly into HTTP response headers without neutralizing semicolons or control characters. This lack of sanitization allows an attacker who controls any part of the cookie data to inject malicious sequences that alter the structure of the Set-Cookie header itself rather than just its content.
The operational impact of this vulnerability is severe, primarily manifesting as Cookie Injection and potential HTTP Response Splitting. By injecting semicolons into fields like name or domain, an attacker can effectively terminate the current cookie attribute and start a new one. This allows for the manipulation of critical security attributes such as Domain, Path, SameSite, or Secure flags. For instance, if an application constructs a session cookie using user-supplied input without proper validation, an attacker could inject a semicolon followed by domain=evil.com to redirect cookies to a malicious server under their control. This widens the scope of the cookie beyond intended boundaries and weakens protections like SameSite which are designed to prevent cross-site request forgery attacks.
Furthermore, the presence of unneutralized control characters introduces the risk of HTTP Response Splitting on permissive backend servers or proxies. Control characters such as carriage returns (CR) and line feeds (LF) can be used to inject additional headers into the response stream. If an application relies on these cookies for authentication or session management, header splitting could allow attackers to modify other parts of the HTTP response, potentially leading to cache poisoning, cross-site scripting via injected content-type headers, or defacement attacks. This vulnerability aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component and is closely related to CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers for XSS Vulnerabilities as well as CWE-601 URL Redirection to Untrusted Site.
The remediation strategy implemented in the patched versions involves rigorous input sanitization within the ResponseCookie rendering process. The fix explicitly strips all control characters from every field including name, content, domain, path, and extension. Additionally, semicolons are stripped from the name, content, domain, and path fields to prevent attribute injection while retaining necessary delimiter behavior for extensions where appropriate. Developers using affected versions must upgrade immediately to version 0.23.35 or 1.0.0-M47 or later. For applications that cannot update instantly, a temporary mitigation involves implementing strict input validation at the application layer before constructing any ResponseCookie objects, ensuring that only alphanumeric characters and safe punctuation are permitted in cookie attributes. This defensive coding practice helps mitigate the risk of injection attacks until the library patch is applied across all dependent services.