Common Weakness Enumeration

CWE-409

Allowed

Improper Handling of Highly Compressed Data (Data Amplification)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.

148 vulnerabilities reference this CWE, most recent first.

GHSA-J9CW-HWQF-85W7

Vulnerability from github – Published: 2026-06-26 16:35 – Updated: 2026-06-26 16:35
VLAI
Summary
Fluentd is Vulnerable to Denial of Service (DoS) via Gzip Decompression Bomb in `in_http` and `in_forward`
Details

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While 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.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

  1. Restrict Network Access
  2. 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.
  3. Use a Reverse Proxy
  4. 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.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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`"
}

GHSA-JFX9-29X2-RV3J

Vulnerability from github – Published: 2025-10-22 19:40 – Updated: 2025-10-23 17:40
VLAI
Summary
pypdf can exhaust RAM via manipulated LZWDecode streams
Details

Impact

An 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.

Patches

This has been fixed in pypdf==6.1.3.

Workarounds

If you cannot upgrade yet, consider applying the changes from PR #3502.

Severity
6.6 (Medium)
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
Show details on source website
To clipboard 

{
  "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"
}

GHSA-JPXJ-2JVG-6JV9

Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2024-05-20 21:47
VLAI
Summary
Data Amplification in HashiCorp go-getter
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.

Severity
4.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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"
}

GHSA-JQPW-QWW5-CJ4C

Vulnerability from github – Published: 2026-06-16 23:01 – Updated: 2026-06-16 23:01
VLAI
Summary
n8n: Denial of Service via ZIP decompression in webhook workflow
Details

Impact

The Compression node's Decompress operation expanded attacker-controlled archives into memory without enforcing limits on decompressed output size. An unauthenticated attacker could send a small compressed archive to a public webhook workflow using this node, causing the n8n process to terminate due to memory exhaustion and disrupting all workflows in the same instance.

Patches

The issue has been fixed in n8n version 2.24.0. Users should upgrade to this version or later to remediate the vulnerability. The fix introduces configurable limits on decompressed output size (N8N_COMPRESSION_NODE_MAX_DECOMPRESSED_SIZE_BYTES) and ZIP entry count (N8N_COMPRESSION_NODE_MAX_ZIP_ENTRIES).

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Disable the Compression node by adding n8n-nodes-base.compression to the NODES_EXCLUDE environment variable. - Restrict public webhook workflows that accept archive file uploads to authenticated endpoints only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T23:01:51Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\nThe Compression node\u0027s Decompress operation expanded attacker-controlled archives into memory without enforcing limits on decompressed output size. An unauthenticated attacker could send a small compressed archive to a public webhook workflow using this node, causing the n8n process to terminate due to memory exhaustion and disrupting all workflows in the same instance. \n\n## Patches\nThe issue has been fixed in n8n version 2.24.0. Users should upgrade to this version or later to remediate the vulnerability. The fix introduces configurable limits on decompressed output size (`N8N_COMPRESSION_NODE_MAX_DECOMPRESSED_SIZE_BYTES`) and ZIP entry count (`N8N_COMPRESSION_NODE_MAX_ZIP_ENTRIES`).\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Disable the Compression node by adding `n8n-nodes-base.compression` to the `NODES_EXCLUDE` environment variable.\n- Restrict public webhook workflows that accept archive file uploads to authenticated endpoints only.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-jqpw-qww5-cj4c",
  "modified": "2026-06-16T23:01:51Z",
  "published": "2026-06-16T23:01:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-jqpw-qww5-cj4c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Denial of Service via ZIP decompression in webhook workflow"
}

GHSA-JXPJ-M582-7727

Vulnerability from github – Published: 2026-07-10 15:31 – Updated: 2026-07-10 15:31
VLAI
Details

Grav before 2.0.1 contains a decompression bomb vulnerability in ZipArchiver::extract() that lacks limits on uncompressed size, file count, and nesting depth. Attackers can supply a crafted ZIP archive that expands to fill available disk space, causing denial of service by exhausting storage resources.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-61455"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-10T15:16:50Z",
    "severity": "HIGH"
  },
  "details": "Grav before 2.0.1 contains a decompression bomb vulnerability in ZipArchiver::extract() that lacks limits on uncompressed size, file count, and nesting depth. Attackers can supply a crafted ZIP archive that expands to fill available disk space, causing denial of service by exhausting storage resources.",
  "id": "GHSA-jxpj-m582-7727",
  "modified": "2026-07-10T15:31:42Z",
  "published": "2026-07-10T15:31:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-928x-9mpw-8h56"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61455"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-before-decompression-bomb-via-ziparchiver"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-M2VV-5VJ5-2HM7

Vulnerability from github – Published: 2022-11-14 12:00 – Updated: 2024-10-11 20:44
VLAI
Summary
Pillow vulnerable to Data Amplification attack.
Details

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pillow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-45198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-22T00:14:54Z",
    "nvd_published_at": "2022-11-14T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).",
  "id": "GHSA-m2vv-5vj5-2hm7",
  "modified": "2024-10-11T20:44:44Z",
  "published": "2022-11-14T12:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45198"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/pull/6402"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/pull/6402/commits/c9f1b35e981075110a23487a8d4a6cbb59a588ea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/commit/11918eac0628ec8ac0812670d9838361ead2d6a4"
    },
    {
      "type": "WEB",
      "url": "https://bugs.gentoo.org/855683"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/409.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2022-42979.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/releases/tag/9.2.0"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202211-10"
    }
  ],
  "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"
    },
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pillow vulnerable to Data Amplification attack."
}

GHSA-M449-CWJH-6PW7

Vulnerability from github – Published: 2025-11-24 22:42 – Updated: 2026-01-21 16:37
VLAI
Summary
pypdf's LZWDecode streams be manipulated to exhaust RAM
Details

Impact

An attacker who uses this vulnerability can craft a PDF which leads to a memory usage of up to 1 GB per stream. This requires parsing the content stream of a page using the LZWDecode filter.

This is a follow up to GHSA-jfx9-29x2-rv3j to align the default limit with the one for zlib.

Patches

This has been fixed in pypdf==6.4.0.

Workarounds

If users cannot upgrade yet, use the line below to overwrite the default in their code:

pypdf.filters.LZW_MAX_OUTPUT_LENGTH = 75_000_000
Severity
6.6 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-24T22:42:07Z",
    "nvd_published_at": "2025-11-26T00:15:51Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn attacker who uses this vulnerability can craft a PDF which leads to a memory usage of up to 1 GB per stream. This requires parsing the content stream of a page using the LZWDecode filter.\n\nThis is a follow up to [GHSA-jfx9-29x2-rv3j](https://github.com/py-pdf/pypdf/security/advisories/GHSA-jfx9-29x2-rv3j) to align the default limit with the one for *zlib*.\n\n### Patches\nThis has been fixed in [pypdf==6.4.0](https://github.com/py-pdf/pypdf/releases/tag/6.4.0).\n\n### Workarounds\nIf users cannot upgrade yet, use the line below to overwrite the default in their code:\n\n```python\npypdf.filters.LZW_MAX_OUTPUT_LENGTH = 75_000_000\n```",
  "id": "GHSA-m449-cwjh-6pw7",
  "modified": "2026-01-21T16:37:13Z",
  "published": "2025-11-24T22:42:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-jfx9-29x2-rv3j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-m449-cwjh-6pw7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66019"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/commit/96186725e5e6f237129a58a97cd19204a9ce40b2"
    },
    {
      "type": "WEB",
      "url": "https://aydinnyunus.github.io/2025/12/20/cve-2025-66019-pypdf-lzw-dos"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.4.0"
    }
  ],
  "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\u0027s LZWDecode streams be manipulated to exhaust RAM"
}

GHSA-MC85-72GR-VM9F

Vulnerability from github – Published: 2026-07-10 00:03 – Updated: 2026-07-10 00:03
VLAI
Summary
Tesla has decompression bomb on response body
Details

Summary

Any Tesla client pipeline that includes Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression eagerly decompresses HTTP response bodies with no size limit. A server under attacker control (or reached via a redirect) can return a tiny gzip-encoded payload that expands into gigabytes of BEAM heap, crashing or freezing the calling process. Stacking multiple content-encoding tokens multiplies the amplification exponentially.

Details

decompress_body/2 in lib/tesla/middleware/compression.ex passes the full response body to :zlib.gunzip/1 or :zlib.unzip/1 with no cap on output size. The list of codec tokens comes from splitting the content-encoding header on commas, and decompress_body/2 recurses once per token. A response advertising content-encoding: gzip, gzip, gzip, gzip triggers four recursive decompression passes. Each gzip layer can expand its input roughly 1000x, so a 284-byte wire payload with four layers inflates to approximately 1 GB at the innermost pass, all materialised as a single binary in the caller's heap.

PoC

  1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
  2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
  3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
  4. Repeated or sufficiently large requests exhaust available memory and crash or freeze the node.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 0.6.0 through 1.18.2 with Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression in its pipeline is vulnerable. The attacker only needs to control a server the client contacts, including via redirects. Fixed in tesla 1.18.3.

Configurations

The application must include Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression in its Tesla middleware pipeline.

Resources

  • Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
  • Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d
Severity
8.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "tesla"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "1.18.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48594"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T00:03:23Z",
    "nvd_published_at": "2026-06-02T20:16:38Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAny Tesla client pipeline that includes `Tesla.Middleware.DecompressResponse` or `Tesla.Middleware.Compression` eagerly decompresses HTTP response bodies with no size limit. A server under attacker control (or reached via a redirect) can return a tiny gzip-encoded payload that expands into gigabytes of BEAM heap, crashing or freezing the calling process. Stacking multiple `content-encoding` tokens multiplies the amplification exponentially.\n\n### Details\n\n`decompress_body/2` in `lib/tesla/middleware/compression.ex` passes the full response body to `:zlib.gunzip/1` or `:zlib.unzip/1` with no cap on output size. The list of codec tokens comes from splitting the `content-encoding` header on commas, and `decompress_body/2` recurses once per token. A response advertising `content-encoding: gzip, gzip, gzip, gzip` triggers four recursive decompression passes. Each gzip layer can expand its input roughly 1000x, so a 284-byte wire payload with four layers inflates to approximately 1 GB at the innermost pass, all materialised as a single binary in the caller\u0027s heap.\n\n### PoC\n\n1. Serve an HTTP response with `content-encoding: gzip, gzip, gzip, gzip` where the body is a 1 GB block of zeros compressed through four successive gzip passes.\n2. Send that response to a Tesla client whose pipeline includes `Tesla.Middleware.DecompressResponse`.\n3. `decompress_body/2` recurses four times without any size check, materialising ~1 GB in the calling process\u0027s heap.\n4. Repeated or sufficiently large requests exhaust available memory and crash or freeze the node.\n\n### Impact\n\nHigh severity (CVSS v4.0: 8.2). Any application using `tesla` 0.6.0 through 1.18.2 with `Tesla.Middleware.DecompressResponse` or `Tesla.Middleware.Compression` in its pipeline is vulnerable. The attacker only needs to control a server the client contacts, including via redirects. Fixed in tesla 1.18.3.\n\n### Configurations\n\nThe application must include `Tesla.Middleware.DecompressResponse` or `Tesla.Middleware.Compression` in its Tesla middleware pipeline.\n\n### Resources\n\n* Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2\n* Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d",
  "id": "GHSA-mc85-72gr-vm9f",
  "modified": "2026-07-10T00:03:23Z",
  "published": "2026-07-10T00:03:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/elixir-tesla/tesla/security/advisories/GHSA-mc85-72gr-vm9f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48594"
    },
    {
      "type": "WEB",
      "url": "https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-48594.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/elixir-tesla/tesla"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-48594"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Tesla has decompression bomb on response body"
}

GHSA-MF9V-MFXR-J63J

Vulnerability from github – Published: 2026-05-11 14:51 – Updated: 2026-06-08 19:52
VLAI
Summary
urllib3: Decompression-bomb safeguards bypassed in parts of the streaming API
Details

Impact

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.

urllib3 can perform decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.

However, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases: 1. During the second HTTPResponse.read(amt=N) call when the response was decompressed using the official Brotli library. 2. When HTTPResponse.drain_conn() was called after the response had been read and decompressed partially (compression algorithm did not matter here).

These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side.

Affected usages

Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:

  1. A response encoded with br is read incrementally with at least two HTTPResponse.read(amt=N) or HTTPResponse.stream(amt=N) calls while using the official Brotli library.
  2. HTTPResponse.drain_conn() is called after response decompression has already started.

Remediation

Upgrade to at least urllib3 version 2.7.0 in which the library: 1. Is more efficient for reads with Brotli. 2. Always skips decompression for HTTPResponse.drain_conn().

If upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases: 1. For the Brotli-specific issue only, switch from brotli to brotlicffi until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396. 2. If your code explicitly calls HTTPResponse.drain_conn(), call HTTPResponse.close() instead when connection reuse is not important.

Credits

The Brotli-specific issue was reported by @kimkou2024. HTTPResponse.drain_conn() inefficiency was reported by @Cycloctane.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.9 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44432"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T14:51:45Z",
    "nvd_published_at": "2026-05-13T16:16:57Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nurllib3\u0027s [streaming API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.\n\nurllib3 can perform decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.\n\nHowever, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases:\n1. During the second `HTTPResponse.read(amt=N)` call when the response was decompressed using the official [Brotli](https://pypi.org/project/brotli/) library.\n2. When `HTTPResponse.drain_conn()` was called after the response had been read and decompressed partially (compression algorithm did not matter here).\n\nThese issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side.\n\n\n### Affected usages\n\nApplications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:\n\n1. A response encoded with `br` is read incrementally with at least two `HTTPResponse.read(amt=N)` or `HTTPResponse.stream(amt=N)` calls while using the official [Brotli](https://pypi.org/project/brotli/) library.\n2. `HTTPResponse.drain_conn()` is called after response decompression has already started.\n\n\n### Remediation\n\nUpgrade to at least urllib3 version 2.7.0 in which the library:\n1. Is more efficient for reads with Brotli.\n2. Always skips decompression for `HTTPResponse.drain_conn()`.\n\nIf upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases:\n1. For the Brotli-specific issue only, switch from [brotli](https://pypi.org/project/brotli/) to [brotlicffi](https://pypi.org/project/brotlicffi/) until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396.\n2. If your code explicitly calls `HTTPResponse.drain_conn()`, call `HTTPResponse.close()` instead when connection reuse is not important.\n\n\n### Credits\n\nThe Brotli-specific issue was reported by @kimkou2024.\n`HTTPResponse.drain_conn()` inefficiency was reported by @Cycloctane.",
  "id": "GHSA-mf9v-mfxr-j63j",
  "modified": "2026-06-08T19:52:23Z",
  "published": "2026-05-11T14:51:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-mf9v-mfxr-j63j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44432"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2026-142.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "urllib3: Decompression-bomb safeguards bypassed in parts of the streaming API"
}

GHSA-MGF9-4VPG-HJ56

Vulnerability from github – Published: 2026-06-15 20:19 – Updated: 2026-06-15 20:19
VLAI
Summary
tornado AsyncHTTPClient accumulates decompressed chunks without size limit (gzip bomb)
Details

Tornado's gzip decompression routines work in limited-size chunks, but have no overall limit for the total size of decompressed chunks that they will accumulate (There has always been a limit for the total compressed size). This allows a malicious server to consume effectively unlimited amounts of memory if it is accessed via SimpleAsyncHTTPClient in its default configuration. HTTPServer is not affected in its default configuration, but it is if decompress_request=True is set.

This bug is fixed in Tornado 6.5.6. max_body_size is now checked both for the compressed and cumulative decompressed size of the response.

Prior to upgrading, this issue can be mitigated by setting decompress_response=False or using CurlAsyncHTTPClient.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tornado"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49855"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:19:28Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Tornado\u0027s gzip decompression routines work in limited-size chunks, but have no overall limit for the total size of decompressed chunks that they will accumulate (There has always been a limit for the total *compressed* size). This allows a malicious server to consume effectively unlimited amounts of memory if it is accessed via SimpleAsyncHTTPClient in its default configuration. `HTTPServer` is not affected in its default configuration, but it is if `decompress_request=True` is set.\n\nThis bug is fixed in Tornado 6.5.6. `max_body_size` is now checked both for the compressed and cumulative decompressed size of the response.\n\nPrior to upgrading, this issue can be mitigated by setting `decompress_response=False` or using `CurlAsyncHTTPClient`.",
  "id": "GHSA-mgf9-4vpg-hj56",
  "modified": "2026-06-15T20:19:28Z",
  "published": "2026-06-15T20:19:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-mgf9-4vpg-hj56"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tornadoweb/tornado"
    }
  ],
  "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": "tornado AsyncHTTPClient accumulates decompressed chunks without size limit (gzip bomb)"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list