Summary
http4k: BasicCookieStorage (renamed InsecureCookieStorage) did not enforce RFC 6265 cookie scoping; new DefaultCookieStorage` is now the default
Workarounds
For deployments that cannot upgrade immediately:
- Use a dedicated
BasicCookieStorageinstance 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
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
| 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.
Frequently Asked Questions
- What is GHSA-PR33-38XX-6R26? GHSA-PR33-38XX-6R26 is a medium-severity security vulnerability in org.http4k:http4k-core (maven), affecting versions >= 6.0.0.0, < 6.48.0.0. It is fixed in 6.48.0.0, 5.42.0.0, 4.51.0.0.
- Which versions of org.http4k:http4k-core are affected by GHSA-PR33-38XX-6R26? org.http4k:http4k-core (maven) versions >= 6.0.0.0, < 6.48.0.0 is affected.
- Is there a fix for GHSA-PR33-38XX-6R26? Yes. GHSA-PR33-38XX-6R26 is fixed in 6.48.0.0, 5.42.0.0, 4.51.0.0. Upgrade to this version or later.
- Is GHSA-PR33-38XX-6R26 exploitable, and should I be worried? Whether GHSA-PR33-38XX-6R26 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-PR33-38XX-6R26 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-PR33-38XX-6R26?
- Upgrade
org.http4k:http4k-coreto 6.48.0.0 or later - Upgrade
org.http4k:http4k-coreto 5.42.0.0 or later - Upgrade
org.http4k:http4k-coreto 4.51.0.0 or later
- Upgrade