Vulnerability-Lookup

GHSA-Q432-RMQV-HH8M

Vulnerability from github – Published: 2026-06-06 12:31 – Updated: 2026-06-09 09:32

Details

Protocol::HTTP2 versions through 1.12 for Perl is vulnerable to a HTTP/2 Bomb.

Protocol::HTTP2's inbound HPACK path has no header-list size limit, so a small HTTP/2 request can expand into large server memory (the "HTTP/2 bomb").

The headers_decode method materialises a full key+value copy per indexed reference with no running size check, and the stream_header_block_add method appends (since version 1.12) every CONTINUATION frame to the per-stream buffer unbounded.

MAX_HEADER_LIST_SIZE (default 65536) is advertised in SETTINGS but never consulted on decode. It is absent from the decoder and from the :limits export tag.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-10725"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-06T10:16:25Z",
    "severity": "HIGH"
  },
  "details": "Protocol::HTTP2 versions through 1.12 for Perl is vulnerable to a HTTP/2 Bomb.\n\nProtocol::HTTP2\u0027s inbound HPACK path has no header-list size limit, so a small HTTP/2 request can expand into large server memory (the \"HTTP/2 bomb\").\n\nThe headers_decode method materialises a full key+value copy per indexed reference with no running size check, and the stream_header_block_add method appends (since version 1.12) every CONTINUATION frame to the per-stream buffer unbounded.\n\nMAX_HEADER_LIST_SIZE (default 65536) is advertised in SETTINGS but never consulted on decode.  It is absent from the decoder and from the :limits export tag.",
  "id": "GHSA-q432-rmqv-hh8m",
  "modified": "2026-06-09T09:32:06Z",
  "published": "2026-06-06T12:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10725"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vlet/p5-Protocol-HTTP2/commit/822bf22224adbd662e8d0b865eeacb2b294d16cd.patch"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/CRUX/Protocol-HTTP2-1.12/source/lib/Protocol/HTTP2/HeaderCompression.pm#L133"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/CRUX/Protocol-HTTP2-1.12/source/lib/Protocol/HTTP2/Stream.pm#L414"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/CRUX/Protocol-HTTP2-1.13/changes"
    },
    {
      "type": "WEB",
      "url": "https://security.metacpan.org/patches/P/Protocol-HTTP2/1.12/CVE-2026-10725-r1.patch"
    },
    {
      "type": "WEB",
      "url": "https://security.metacpan.org/patches/P/Protocol-HTTP2/1.12/CVE-2026-10725-r2.patch"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/06/7"
    }
  ],
  "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"
    }
  ]
}

GHSA-QF49-6JM2-H67M

Vulnerability from github – Published: 2026-07-27 15:32 – Updated: 2026-07-27 15:32

Details

Mattermost versions 11.6.x <= 11.6.5, 10.11.x <= 10.11.20, 11.8.x <= 11.8.1, 11.7.x <= 11.7.4 fail to limit the number of frames and enforce the file size cap on animated GIF uploads, which allows an authenticated attacker to cause a denial of service via a crafted animated GIF uploaded as a custom emoji.. Mattermost Advisory ID: MMSA-2026-00695

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-10819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T15:16:46Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 11.6.x \u003c= 11.6.5, 10.11.x \u003c= 10.11.20, 11.8.x \u003c= 11.8.1, 11.7.x \u003c= 11.7.4 fail to limit the number of frames and enforce the file size cap on animated GIF uploads, which allows an authenticated attacker to cause a denial of service via a crafted animated GIF uploaded as a custom emoji.. Mattermost Advisory ID: MMSA-2026-00695",
  "id": "GHSA-qf49-6jm2-h67m",
  "modified": "2026-07-27T15:32:31Z",
  "published": "2026-07-27T15:32:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10819"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ]
}

GHSA-QRVQ-68C2-7GRW

Vulnerability from github – Published: 2026-02-24 16:04 – Updated: 2026-02-27 20:03

Summary

nats-server websockets are vulnerable to pre-auth memory DoS

Details

Impact

The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression. The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.

An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.

The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.

The fix was to bounds the decompression to fail once the message was too large, instead of continuing on.

Patches

This was released in nats-server without being highlighted as a security issue. It should have been, this was an oversight. Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.

This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.

Workarounds

This only affects deployments which use WebSockets and which expose the network port to untrusted end-points.

References

This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0-RC.1"
            },
            {
              "fixed": "2.12.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27571"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-24T16:04:53Z",
    "nvd_published_at": "2026-02-24T17:29:03Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression.  The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.\n\nAn attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.\n\nThe use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.\n\nThe fix was to bounds the decompression to fail once the message was too large, instead of continuing on.\n\n### Patches\n\nThis was released in nats-server without being highlighted as a security issue.  It should have been, this was an oversight.  Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.\n\nThis was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.\n\n### Workarounds\n\nThis only affects deployments which use WebSockets and which expose the network port to untrusted end-points.\n\n### References\n\nThis was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).",
  "id": "GHSA-qrvq-68c2-7grw",
  "modified": "2026-02-27T20:03:26Z",
  "published": "2026-02-24T16:04:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-qrvq-68c2-7grw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27571"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/commit/f77fb7c4535e6727cc1a2899cd8e6bbdd8ba2017"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/nats-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/releases/tag/v2.11.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/releases/tag/v2.12.3"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4533"
    }
  ],
  "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"
    }
  ],
  "summary": "nats-server websockets are vulnerable to pre-auth memory DoS"
}

GHSA-R3XG-RG9J-67FV

Vulnerability from github – Published: 2026-06-03 21:13 – Updated: 2026-07-21 15:04

Summary

Docling: Unsafe Archive Extraction and XML Parsing in METS-GBS Backend

Details

Impact

The METS-GBS backend's XML parsing and the input document format detection lacked security controls, enabling: - XML External Entity (XXE) attacks to read local files or cause denial of service - Decompression bombs (zip bombs) to exhaust memory and disk space - Unbounded archive extraction consuming system resources

An attacker could craft malicious METS-GBS archives that, when processed, could read sensitive files, exhaust system resources, or cause application crashes.

Patches

Fixed in version 2.91.0. The fix implements: - Secure XML parsing with resolve_entities=False, load_dtd=False, and no_network=True - Configurable limits: 300 MB total extraction size, 10 MB per file, 1000 member count - Cumulative size tracking across all extractions - Early termination when limits are exceeded - Secure format detection of METS-GBS tar archives with _detect_mets_gbs() method: maximum file size (10 MB per file), maximum member count (1000 members), and exception handling to gracefully fail when limits are exceeded

Workarounds

Avoid processing METS-GBS archives from untrusted sources. If necessary, pre-validate archives in an isolated environment with resource limits.

References

Fix release: v2.91.0

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "docling"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.45.0"
            },
            {
              "fixed": "2.91.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409",
      "CWE-611",
      "CWE-776"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-03T21:13:32Z",
    "nvd_published_at": "2026-06-26T16:16:30Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe METS-GBS backend\u0027s XML parsing and the input document format detection lacked security controls, enabling:\n- XML External Entity (XXE) attacks to read local files or cause denial of service\n- Decompression bombs (zip bombs) to exhaust memory and disk space\n- Unbounded archive extraction consuming system resources\n\nAn attacker could craft malicious METS-GBS archives that, when processed, could read sensitive files, exhaust system resources, or cause application crashes.\n\n### Patches\nFixed in version 2.91.0. The fix implements:\n- Secure XML parsing with `resolve_entities=False`, `load_dtd=False`, and `no_network=True`\n- Configurable limits: 300 MB total extraction size, 10 MB per file, 1000 member count\n- Cumulative size tracking across all extractions\n- Early termination when limits are exceeded\n- Secure format detection of METS-GBS tar archives with `_detect_mets_gbs()` method: maximum file size (10 MB per file), maximum member count (1000 members), and exception handling to gracefully fail when limits are exceeded\n\n### Workarounds\nAvoid processing METS-GBS archives from untrusted sources. If necessary, pre-validate archives in an isolated environment with resource limits.\n\n### References\n- Fix release: [v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0)",
  "id": "GHSA-r3xg-rg9j-67fv",
  "modified": "2026-07-21T15:04:20Z",
  "published": "2026-06-03T21:13:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/docling-project/docling/security/advisories/GHSA-r3xg-rg9j-67fv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44018"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/docling-project/docling"
    },
    {
      "type": "WEB",
      "url": "https://github.com/docling-project/docling/releases/tag/v2.91.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/docling/PYSEC-2026-2144.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docling: Unsafe Archive Extraction and XML Parsing in METS-GBS Backend"
}

GHSA-R44J-6VWC-M7HX

Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-21 03:31

Details

OpenClaw versions prior to 2026.3.2 contain an archive extraction vulnerability in the tar.bz2 installer path that bypasses safety checks enforced on other archive formats. Attackers can craft malicious tar.bz2 skill archives to bypass special-entry blocking and extracted-size guardrails, causing local denial of service during skill installation.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

6.7 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-32044"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T01:17:06Z",
    "severity": "MODERATE"
  },
  "details": "OpenClaw versions prior to 2026.3.2 contain an archive extraction vulnerability in the tar.bz2 installer path that bypasses safety checks enforced on other archive formats. Attackers can craft malicious tar.bz2 skill archives to bypass special-entry blocking and extracted-size guardrails, causing local denial of service during skill installation.",
  "id": "GHSA-r44j-6vwc-m7hx",
  "modified": "2026-03-21T03:31:13Z",
  "published": "2026-03-21T03:31:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-77hf-7fqf-f227"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32044"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/0dbb92dd2bcf9a32379d11c0f11ed016669dae3e"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-tar-archive-safety-bypass-in-skills-installation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/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-R5WC-GHWH-WJV9

Vulnerability from github – Published: 2026-10-02 12:31 – Updated: 2026-10-02 12:31

Details

Improper handling of highly compressed data (data amplification) vulnerability in Apache Thrift Go bindings.

This issue affects Apache Thrift: before 0.25.0.

Users are recommended to upgrade to version 0.25.0, which fixes the issue.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-94637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-02T12:17:23Z",
    "severity": "HIGH"
  },
  "details": "Improper handling of highly compressed data (data amplification) vulnerability in Apache Thrift Go bindings.\n\n\n\nThis issue affects Apache Thrift: before 0.25.0.\n\n\n\nUsers are recommended to upgrade to version 0.25.0, which fixes the issue.",
  "id": "GHSA-r5wc-ghwh-wjv9",
  "modified": "2026-10-02T12:31:18Z",
  "published": "2026-10-02T12:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94637"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/33otcgbqd27wf6qq810q56znzbomnhg1"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/6hxll1jcnod9gfr225tz7my08lpj3jmt"
    }
  ],
  "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/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-R7FM-3PQM-WW5W

Vulnerability from github – Published: 2025-07-10 17:50 – Updated: 2025-07-10 23:21

Summary

Chall-Manager's scenario decoding process does not check for zip bombs

Details

Impact

When decoding a scenario (i.e. a zip archive), the size of the decoded content is not checked, potentially leading to zip bombs decompression. Exploitation does not require authentication nor authorization, so anyone can exploit it. It should nonetheless not be exploitable as it is highly recommended to bury Chall-Manager deep within the infrastructure due to its large capabilities, so no users could reach the system.

Patches

Patch has been implemented by commit 14042aa and shipped in v0.1.4.

Workarounds

No workaround exist.

References

N/A.

Severity

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ctfer-io/chall-manager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53633"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-10T17:50:25Z",
    "nvd_published_at": "2025-07-10T20:15:27Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen decoding a scenario (i.e. a zip archive), the size of the decoded content is not checked, potentially leading to zip bombs decompression.\nExploitation does not require authentication nor authorization, so anyone can exploit it. It should nonetheless not be exploitable as it is highly recommended to bury Chall-Manager deep within the infrastructure due to its large capabilities, so no users could reach the system.\n\n### Patches\n\nPatch has been implemented by [commit `14042aa`](https://github.com/ctfer-io/chall-manager/commit/14042aa66a577caee777e10fe09adcf2587d20dd) and shipped in [`v0.1.4`](https://github.com/ctfer-io/chall-manager/releases/tag/v0.1.4).\n\n### Workarounds\n\nNo workaround exist.\n\n### References\n\nN/A.",
  "id": "GHSA-r7fm-3pqm-ww5w",
  "modified": "2025-07-10T23:21:54Z",
  "published": "2025-07-10T17:50:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ctfer-io/chall-manager/security/advisories/GHSA-r7fm-3pqm-ww5w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ctfer-io/chall-manager/commit/14042aa66a577caee777e10fe09adcf2587d20dd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ctfer-io/chall-manager"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ctfer-io/chall-manager/releases/tag/v0.1.4"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Chall-Manager\u0027s scenario decoding process does not check for zip bombs"
}

GHSA-R7GV-HXJ8-94C4

Vulnerability from github – Published: 2026-08-24 03:31 – Updated: 2026-08-24 03:31

Details

exceljs-hardened before 5.0.0 decompresses all entries from supplied xlsx archives into memory without limits on entry size, total size, or compression ratio. Attackers can upload highly compressed workbooks that expand to gigabytes in memory, exhausting available resources and causing denial of service.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-78206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-24T01:16:57Z",
    "severity": "HIGH"
  },
  "details": "exceljs-hardened before 5.0.0 decompresses all entries from supplied xlsx archives into memory without limits on entry size, total size, or compression ratio. Attackers can upload highly compressed workbooks that expand to gigabytes in memory, exhausting available resources and causing denial of service.",
  "id": "GHSA-r7gv-hxj8-94c4",
  "modified": "2026-08-24T03:31:05Z",
  "published": "2026-08-24T03:31:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mateocallec/exceljs-hardened/security/advisories/GHSA-7cvf-3r55-r39q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/exceljs/exceljs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/exceljs/exceljs/blob/v4.4.0/lib/xlsx/xlsx.js#L257-L281"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/exceljs-through-uncontrolled-resource-consumption-via-unbounded-xlsx-decompression"
    }
  ],
  "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/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-R89F-H4HF-P5H7

Vulnerability from github – Published: 2026-08-19 21:30 – Updated: 2026-08-19 21:30

Details

Tanium addressed a compression bomb vulnerability in Threat Response.

Severity

3.1 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-75476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-19T21:17:37Z",
    "severity": "LOW"
  },
  "details": "Tanium addressed a compression bomb vulnerability in Threat Response.",
  "id": "GHSA-r89f-h4hf-p5h7",
  "modified": "2026-08-19T21:30:38Z",
  "published": "2026-08-19T21:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75476"
    },
    {
      "type": "WEB",
      "url": "https://security.tanium.com/TAN-2026-021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RCW4-F5RP-G42V

Vulnerability from github – Published: 2026-09-29 18:25 – Updated: 2026-09-29 18:25

Summary

adm-zip: Decompression-bomb protection (fix for CVE-2026-39244) can be bypassed by declaring uncompressed size as 0

Details

Affected package: adm-zip (npm) Affected version: 0.6.0

Summary

The fix shipped for CVE-2026-39244 (methods/inflater.js) caps zlib's decompression output via maxOutputLength: expectedLength, where expectedLength is read directly from the ZIP entry's attacker-controlled "uncompressed size" header field (CENLEN/LOCLEN). This cap is only applied when expectedLength > 0:

const option = version >= 15 && expectedLength > 0 ? { maxOutputLength: expectedLength } : {};
return zlib.inflateRawSync(inbuf, option);

If an attacker sets the declared uncompressed-size field to exactly 0, this condition is false, option becomes {}, and no output cap is passed to zlib at all. Node then falls back to zlib's own internal default limit (several GB), so a small, highly-compressible payload can still be decompressed to a very large size in memory -- the same class of resource-exhaustion issue the original CVE addressed, just triggered differently.

Steps to Reproduce

Build a ZIP archive containing one DEFLATE-compressed entry whose real content is highly redundant (e.g. several MB of a repeated byte, achieving close to the ~1032:1 theoretical raw-DEFLATE compression ratio).
Patch the entry's declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to 0. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real decompressed output, not the declared size.
Load the archive with new AdmZip(buffer) and call .getEntries()[0].getData() (or readFile/readAsText/extractAllTo/etc. -- all share the same code path).
Observe: decompression succeeds and returns the full-size buffer with no size restriction applied, whereas the same real data with an honest (but undersized) declared value correctly throws Cannot create a Buffer larger than N bytes.

Proof of Concept

Attached script demonstrates a controlled A/B comparison using the identical real payload in both cases -- only the declared-size header field differs:

Control (declared size = 1024 bytes, deliberately smaller than the true 4MB output): correctly throws, proving the cap mechanism works when expectedLength > 0.
Bypass (declared size = 0, identical real payload): succeeds and returns the full 4,194,304-byte buffer with zero restriction.

Verified reproducible across 3 independent runs.

Impact

Any application that calls adm-zip's read/extract methods on an untrusted ZIP file (upload handlers, CI artifact extraction, email attachment scanning, etc.) can be made to allocate an amount of memory bounded only by zlib's own internal default rather than any limit the application or adm-zip intends -- a small (tens-of-MB) upload can trigger multi-GB memory consumption, risking process crash/OOM.

Suggested Fix

Apply maxOutputLength unconditionally (e.g. defaulting to a sane absolute ceiling, or always passing the declared size regardless of whether it's 0), and/or add an independent compression-ratio check that doesn't rely solely on the attacker-supplied size field.

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "adm-zip"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T18:25:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "**Affected package:** adm-zip (npm)\n**Affected version:** 0.6.0\n\n## Summary\n\nThe fix shipped for CVE-2026-39244 (`methods/inflater.js`) caps zlib\u0027s decompression output via `maxOutputLength: expectedLength`, where `expectedLength` is read directly from the ZIP entry\u0027s attacker-controlled \"uncompressed size\" header field (`CENLEN`/`LOCLEN`). This cap is only applied when `expectedLength \u003e 0`:\n\n```js\nconst option = version \u003e= 15 \u0026\u0026 expectedLength \u003e 0 ? { maxOutputLength: expectedLength } : {};\nreturn zlib.inflateRawSync(inbuf, option);\n```\n\nIf an attacker sets the declared uncompressed-size field to exactly **0**, this condition is false, `option` becomes `{}`, and no output cap is passed to zlib at all. Node then falls back to zlib\u0027s own internal default limit (several GB), so a small, highly-compressible payload can still be decompressed to a very large size in memory -- the same class of resource-exhaustion issue the original CVE addressed, just triggered differently.\n\n## Steps to Reproduce\n\n1. Build a ZIP archive containing one DEFLATE-compressed entry whose real content is highly redundant (e.g. several MB of a repeated byte, achieving close to the ~1032:1 theoretical raw-DEFLATE compression ratio).\n2. Patch the entry\u0027s declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to `0`. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real decompressed output, not the declared size.\n3. Load the archive with `new AdmZip(buffer)` and call `.getEntries()[0].getData()` (or `readFile`/`readAsText`/`extractAllTo`/etc. -- all share the same code path).\n4. Observe: decompression succeeds and returns the full-size buffer with no size restriction applied, whereas the same real data with an honest (but undersized) declared value correctly throws `Cannot create a Buffer larger than N bytes`.\n\n## Proof of Concept\n\nAttached script demonstrates a controlled A/B comparison using the identical real payload in both cases -- only the declared-size header field differs:\n\n- **Control** (declared size = 1024 bytes, deliberately smaller than the true 4MB output): correctly throws, proving the cap mechanism works when `expectedLength \u003e 0`.\n- **Bypass** (declared size = 0, identical real payload): succeeds and returns the full 4,194,304-byte buffer with zero restriction.\n\nVerified reproducible across 3 independent runs.\n\n## Impact\n\nAny application that calls adm-zip\u0027s read/extract methods on an untrusted ZIP file (upload handlers, CI artifact extraction, email attachment scanning, etc.) can be made to allocate an amount of memory bounded only by zlib\u0027s own internal default rather than any limit the application or adm-zip intends -- a small (tens-of-MB) upload can trigger multi-GB memory consumption, risking process crash/OOM.\n\n## Suggested Fix\n\nApply `maxOutputLength` unconditionally (e.g. defaulting to a sane absolute ceiling, or always passing the declared size regardless of whether it\u0027s 0), and/or add an independent compression-ratio check that doesn\u0027t rely solely on the attacker-supplied size field.",
  "id": "GHSA-rcw4-f5rp-g42v",
  "modified": "2026-09-29T18:25:20Z",
  "published": "2026-09-29T18:25:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/security/advisories/GHSA-rcw4-f5rp-g42v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cthackers/adm-zip"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/releases/tag/v0.6.1"
    }
  ],
  "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": "adm-zip: Decompression-bomb protection (fix for CVE-2026-39244) can be bypassed by declaring uncompressed size as 0"
}

CWE-409

Improper Handling of Highly Compressed Data (Data Amplification)

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Summary

Steps to Reproduce

Proof of Concept

Impact

Suggested Fix