GHSA-pr33-38xx-6r26 http4k: BasicCookieStorage` (renamed `InsecureCookieStorage`) did not enforce RFC 6265 cookie scoping; new `DefaultCookieStorage` is now the default

• Maven org.http4k:http4k-core: >= 6.0.0.0, < 6.48.0.0 → fixed in 6.48.0.0 • Maven org.http4k:http4k-core: >= 5.0.0.0, < 5.42.0.0 → fixed in 5.42.0.0 • Maven org.http4k:http4k-core: < 4.51.0.0 → fixed in 4.51.0.0

Impact The previous `BasicCookieStorage` did not enforce RFC 6265 scoping rules around cookie domain, path, and `Secure` attribute. A client using a single storage instance to talk to multiple origins could have cookies leak across domains, or have `Secure` cookies sent over plain HTTP — the deprecation message states it bluntly: *"BasicCookieStorage has no domain/path/scheme scoping and leaks cookies across origins. Use DefaultCookieStorage instead."* Who is affected: any client using `BasicCookieStorage` directly with cookies for more than one origin or scheme. Single-origin uses are unaffected. Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | 6.48.0.0 | Community | | v5.x (LTS) | 5.42.0.0 | Enterprise — contact [email protected] | | v4.x (LTS) | 4.51.0.0 | Enterprise — contact [email protected] | The fix introduces `DefaultCookieStorage` (RFC 6265 compliant) as the drop-in default; `BasicCookieStorage` is renamed `InsecureCookieStorage` and remains available for callers with a deliberate need for the old behaviour. Workarounds For deployments that cannot upgrade immediately: • Use a dedicated `BasicCookieStorage` instance per origin / scheme, or • Switch to a separate RFC 6265-compliant cookie store implementation. References • Fix release: v6.48.0.0 • Cookie storage rewrite: `6a9b44d743` • Background: RFC 6265 — HTTP State Management Mechanism