GHSA-PR33-38XX-6R26

Vulnerability from github – Published: 2026-06-19 21:16 – Updated: 2026-06-19 21:16
VLAI
Summary
http4k: BasicCookieStorage` (renamed `InsecureCookieStorage`) did not enforce RFC 6265 cookie scoping; new `DefaultCookieStorage` is now the default
Details

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 enterprise@http4k.org
v4.x (LTS) 4.51.0.0 Enterprise — contact enterprise@http4k.org

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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4k:http4k-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0.0"
            },
            {
              "fixed": "6.48.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4k:http4k-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0.0"
            },
            {
              "fixed": "5.42.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4k:http4k-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.51.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:16:07Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe 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 \u2014 the deprecation message states it bluntly: *\"BasicCookieStorage has no domain/path/scheme scoping and leaks cookies across origins. Use DefaultCookieStorage instead.\"*\n\n**Who is affected:** any client using `BasicCookieStorage` directly with cookies for more than one origin or scheme. Single-origin uses are unaffected.\n\n### Patches\n\n| Line | Fixed in | Edition |\n|------|----------|---------|\n| v6.x (Community) | **6.48.0.0** | Community |\n| v5.x (LTS) | **5.42.0.0** | Enterprise \u2014 contact [enterprise@http4k.org](mailto:enterprise@http4k.org) |\n| v4.x (LTS) | **4.51.0.0** | Enterprise \u2014 contact [enterprise@http4k.org](mailto:enterprise@http4k.org) |\n\nThe 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.\n\n### Workarounds\n\nFor deployments that cannot upgrade immediately:\n- Use a dedicated `BasicCookieStorage` instance per origin / scheme, or\n- Switch to a separate RFC 6265-compliant cookie store implementation.\n\n### References\n\n- Fix release: [v6.48.0.0](https://github.com/http4k/http4k/releases/tag/6.48.0.0)\n- Cookie storage rewrite: [`6a9b44d743`](https://github.com/http4k/http4k/commit/6a9b44d743)\n- Background: [RFC 6265 \u2014 HTTP State Management Mechanism](https://datatracker.ietf.org/doc/html/rfc6265)",
  "id": "GHSA-pr33-38xx-6r26",
  "modified": "2026-06-19T21:16:07Z",
  "published": "2026-06-19T21:16:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/http4k/http4k/security/advisories/GHSA-pr33-38xx-6r26"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4k/http4k/commit/6a9b44d743"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc6265"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/http4k/http4k"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4k/http4k/releases/tag/6.48.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "http4k: BasicCookieStorage` (renamed `InsecureCookieStorage`) did not enforce RFC 6265 cookie scoping; new `DefaultCookieStorage` is now the default"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…