{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4k:http4k-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0.0"
            },
            {
              "fixed": "6.49.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"
            },
            {
              "last_affected": "4.48.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T21:52:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`ServerFilters.GZip` and `RequestFilters.GunZip` (and the underlying `Gzip` functions used to decompress request bodies) did not impose any cap on the decompressed size. A small malicious gzip-encoded request body (on the order of kilobytes) could decompress to gigabytes, exhausting the JVM heap and denying service to other clients.\n\n**Who is affected:** any http4k server that accepts gzip-encoded requests via `ServerFilters.GZip` or `RequestFilters.GunZip`. Exploitable by any unauthenticated client. The vulnerability was introduced on 2017-08-01 (commit `2618fe08f9`) and was present for ~9 years.\n\n### Patches\n\n| Line | Fixed in | Edition |\n|------|----------|---------|\n| v6.x (Community) | **6.49.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 caps decompression at 10MB by default; oversized requests through `ServerFilters.GZip` / `RequestFilters.GunZip` now return `413 Request Entity Too Large`, and decompressing elsewhere throws `SizeLimitExceededException`. The keyed `hmacSHA256` helper and other safe paths are unaffected.\n\n### Workarounds\n\nFor deployments that cannot upgrade immediately:\n- Replace the `GZip` / `GunZip` filters with custom versions that wrap the decompressed `InputStream` in a size-limited reader, or\n- Strip gzip-encoded request support at the edge (CDN, reverse proxy, or load balancer).\n\n### References\n\n- Vulnerability introduced: [`2618fe08f9`](https://github.com/http4k/http4k/commit/2618fe08f9)\n- Fix release: [v6.49.0.0](https://github.com/http4k/http4k/releases/tag/6.49.0.0)\n- Background: [CWE-409 \u2014 Improper Handling of Highly Compressed Data](https://cwe.mitre.org/data/definitions/409.html)",
  "id": "GHSA-g4w2-6h2r-3m3w",
  "modified": "2026-08-17T21:58:23Z",
  "published": "2026-08-17T21:52:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/http4k/http4k/security/advisories/GHSA-g4w2-6h2r-3m3w"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/http4k/http4k"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4k/http4k/releases/tag/6.49.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "http4k: Unbounded gzip decompression in `ServerFilters.GZip` / `RequestFilters.GunZip` allowed memory-exhaustion DoS"
}