Vulnerability-Lookup

GHSA-M449-CWJH-6PW7

Vulnerability from github – Published: 2025-11-24 22:42 – Updated: 2026-01-21 16:37

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

JSON

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

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

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.
Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
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

JSON

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

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:

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

JSON

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

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

JSON

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

GHSA-MPW6-HVJ8-87HQ

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

Details

vLLM versions before 0.28.0 fail to validate audio sample rate headers in the transcription endpoint, allowing authenticated clients to bypass duration checks. Attackers can submit forged FLAC headers with inflated sample rates to trigger excessive memory allocation and crash the API server process affecting all tenants.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-90555"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-12T13:16:54Z",
    "severity": "HIGH"
  },
  "details": "vLLM versions before 0.28.0 fail to validate audio sample rate headers in the transcription endpoint, allowing authenticated clients to bypass duration checks. Attackers can submit forged FLAC headers with inflated sample rates to trigger excessive memory allocation and crash the API server process affecting all tenants.",
  "id": "GHSA-mpw6-hvj8-87hq",
  "modified": "2026-09-12T15:31:50Z",
  "published": "2026-09-12T15:31:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-99f2-hwrc-gvq8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90555"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vllm-before-0.28.0-denial-of-service-via-audio-header"
    }
  ],
  "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-PF83-6PPH-CPGR

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

Details

Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 fail to limit the amount of memory allocated when decoding uploaded image files which allows an authenticated user to cause excessive server memory consumption and potential denial of service via uploading a specially crafted image as a profile picture, channel file attachment, team icon, or custom brand image. Mattermost Advisory ID: MMSA-2026-00719

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-15814"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-14T11:17:03Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 11.9.x \u003c= 11.9.0, 11.8.x \u003c= 11.8.4, 11.7.x \u003c= 11.7.7, 10.11.x \u003c= 10.11.22 fail to limit the amount of memory allocated when decoding uploaded image files which allows an authenticated user to cause excessive server memory consumption and potential denial of service via uploading a specially crafted image as a profile picture, channel file attachment, team icon, or custom brand image. Mattermost Advisory ID: MMSA-2026-00719",
  "id": "GHSA-pf83-6pph-cpgr",
  "modified": "2026-09-14T12:31:38Z",
  "published": "2026-09-14T12:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15814"
    },
    {
      "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-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"
}

CWE-409

Improper Handling of Highly Compressed Data (Data Amplification)

Impact

Patches

Workarounds

Summary

Details

PoC

Impact

Configurations

Resources

Impact

Affected usages

Remediation

Credits

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References