GHSA-pr33-38xx-6r26
http4k: BasicCookieStorage` (renamed `InsecureCookieStorage`) did not enforce RFC 6265 cookie scoping; new `DefaultCookieStorage` is now the default
Blast Radius
org.http4k:http4k-core☕org.http4k:http4k-core☕org.http4k:http4k-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.http4k:http4k-core | ≥ 6.0.0.0&&< 6.48.0.0 | 6.48.0.0 |
| ☕Maven | org.http4k:http4k-core | ≥ 5.0.0.0&&< 5.42.0.0 | 5.42.0.0 |
| ☕Maven | org.http4k:http4k-core | all versions | 4.51.0.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.http4k:http4k-core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.http4k:http4k-core to 6.48.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pr33-38xx-6r26 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-pr33-38xx-6r26 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-pr33-38xx-6r26. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-pr33-38xx-6r26 in your dependencies?
O3 detects GHSA-pr33-38xx-6r26 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.