http4k CVE-2026-100725

Exploitation requires that the application reuse a SINGLE BasicCookieStorage instance (the client-side store used by ClientFilters.Cookies) to talk to MORE THAN ONE origin or scheme; clients that dedicate a storage instance per origin are explicitly not affected. The concrete failure is that BasicCookieStorage does not enforce RFC 6265 §5.3/§5.4 scoping for cookie Domain, Path, and the Secure attribute, so stored cookies are returned for every outgoing request regardless of host or scheme. Realistic impact further requires an attacker-controlled or attacker-observable second destination (another origin the client contacts, or a plain-HTTP path over which a Secure cookie is transmitted) to capture the leaked value. Limiting factors: it is a client library flaw (not a server-side remote exploit), affects only versions before 6.48.0.0 / 5.42.0.0 / 4.51.0.0, and depends on the developer's non-single-origin storage configuration.

This is a moderate, conditional client-side confidentiality flaw - not a high-urgency issue despite the vendor's 8.3 CVSS 4.0. The vendor vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L) is internally contradictory: it uses AC:L yet also sets AT:P (attack requirements present), and the AT:P correctly reflects the core limiting condition - a single BasicCookieStorage instance must be shared across more than one origin or scheme, which is a specific (non-single-origin) usage pattern the developer must have adopted. Realistic complexity is therefore higher than AC:L implies. VI:L (integrity) is generous for what is fundamentally a disclosure-only weakness (CWE-200); leaked cookies could indirectly enable request forgery, but the direct impact is confidentiality. There is NO EPSS score, NO CISA KEV listing, and NO public POC in the provided data, so exploitation is theoretical. SSVC framing: exploitation status is 'none', automatable is unlikely (requires attacker to control/observe a second origin the vulnerable client also talks to), technical impact partial. This is best treated as a hygiene/dependency-upgrade item rather than an emergency patch, prioritized higher only for clients demonstrably using one shared cookie store across multiple hosts/schemes.

An http4k-based client uses a single BasicCookieStorage instance (via ClientFilters.Cookies) to communicate with multiple backends - e.g., an internal auth service over HTTPS and a separate reporting API. Because the store ignores RFC 6265 domain/path/Secure scoping, a session cookie set by the auth origin is attached to requests sent to the other origin (or over plain HTTP), disclosing it to an unintended host or an on-path network observer. No public exploit code is identified; exploitation depends on the victim application's own multi-origin storage configuration.