Common Weakness Enumeration

CWE-789

Allowed

Memory Allocation with Excessive Size Value

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

406 vulnerabilities reference this CWE, most recent first.

GHSA-5VRW-QJXW-89R5

Vulnerability from github – Published: 2026-03-19 18:31 – Updated: 2026-03-19 21:23
VLAI
Summary
Metricbeat Allocates Memory with Excessive Size Value Leading to Denial of Service
Details

Memory Allocation with Excessive Size Value (CWE-789) in the Prometheus remote_write HTTP handler in Metricbeat can lead Denial of Service via Excessive Allocation (CAPEC-130).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/elastic/beats/v7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.0-alpha2.0.20260112100137-de072c4e371e"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26931"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T21:23:04Z",
    "nvd_published_at": "2026-03-19T17:16:23Z",
    "severity": "MODERATE"
  },
  "details": "Memory Allocation with Excessive Size Value (CWE-789) in the Prometheus remote_write HTTP handler in Metricbeat can lead Denial of Service via Excessive Allocation (CAPEC-130).",
  "id": "GHSA-5vrw-qjxw-89r5",
  "modified": "2026-03-19T21:23:04Z",
  "published": "2026-03-19T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26931"
    },
    {
      "type": "WEB",
      "url": "https://github.com/elastic/beats/commit/de072c4e371eafeb2a42d65b9ad513f666e4ffd7"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/metricbeat-8-19-13-9-2-5-security-update-esa-2026-09/385532"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/elastic/beats"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Metricbeat Allocates Memory with Excessive Size Value Leading to Denial of Service"
}

GHSA-5WRP-CWCJ-Q835

Vulnerability from github – Published: 2026-05-28 17:04 – Updated: 2026-06-09 11:53
VLAI
Summary
opentelemetry-go's baggage parsing no longer caps raw header length
Details

Summary

https://github.com/open-telemetry/opentelemetry-go/pull/7880 removed raw-length rejection and it causes Parse to process arbitrarily large/invalid baggage headers and log errors, enabling DoS via oversized inputs.

Details

The commit removes the upfront baggage-string length check and the per-member size guard in parsing. Parse now walks the entire input with strings.SplitSeq and skips invalid members while continuing to process the rest. For very large or malformed baggage headers, the parser still fully tokenizes and percent-decodes each member, and errors are forwarded to the global error handler (default logging). This lets a remote client send oversized/invalid headers to trigger excessive CPU/memory work and potentially large log output before any size limit is enforced, creating a denial-of-service risk in services that do not already enforce strict header size limits.

Summary: - In baggage/baggage.go, parseMember performs full parsing and PathUnescape on the entire member without any size guard, amplifying work for large inputs. Parse no longer checks bStr length and continues processing invalid members, so oversized/invalid headers are fully parsed instead of being rejected early. - In propagation/baggage.go, parsing errors from attacker-controlled headers are sent to the global error handler (default logging), which can amplify oversized-input impact.

PoC

baggage_dos_poc.tar.gz

Impact

The issue is reachable through standard propagation parsing (in-scope) and can be exploited remotely to cause CPU/log amplification, but the impact is availability-only and bounded by transport header limits and configurable error handling, supporting a medium severity rather than high/critical.

baggage.Parse iterates over all list members with strings.SplitSeq and skips invalid members while continuing, without a raw-length guard. parseMember performs full parsing and PathUnescape on each member, and propagation.Baggage forwards parsing errors to the global error handler, which logs by default. A remote client can therefore send oversized/invalid baggage headers that bypass the 8KB limit for valid members, causing extra CPU work and large log output, resulting in availability/log amplification in services that accept large headers and use the default handler.

Assumptions:

  • An instrumented service uses the OpenTelemetry baggage propagator for inbound request parsing.
  • Attackers can send oversized or malformed baggage headers that pass the hosting server/proxy header size limits.
  • The default error handler is used or logs are otherwise emitted for parse errors.
  • Inbound request parsing with propagation.Baggage
  • Oversized/invalid baggage headers accepted by the HTTP/gRPC stack
  • Error handler not suppressing parse errors
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/baggage"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.41.0"
            },
            {
              "fixed": "1.42.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.41.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/propagation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.41.0"
            },
            {
              "fixed": "1.42.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.41.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/baggage"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.43.0"
            },
            {
              "fixed": "1.44.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.43.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/propagation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.43.0"
            },
            {
              "fixed": "1.44.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.43.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-28T17:04:19Z",
    "nvd_published_at": "2026-06-04T16:16:37Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nhttps://github.com/open-telemetry/opentelemetry-go/pull/7880 removed raw-length rejection and it causes `Parse` to process arbitrarily large/invalid baggage headers and log errors, enabling DoS via oversized inputs.\n\n\n### Details\n\nThe commit removes the upfront baggage-string length check and the per-member size guard in parsing. `Parse` now walks the entire input with `strings.SplitSeq` and skips invalid members while continuing to process the rest. For very large or malformed `baggage` headers, the parser still fully tokenizes and percent-decodes each member, and errors are forwarded to the global error handler (default logging). This lets a remote client send oversized/invalid headers to trigger excessive CPU/memory work and potentially large log output before any size limit is enforced, creating a denial-of-service risk in services that do not already enforce strict header size limits.\n\nSummary:\n- In `baggage/baggage.go`, `parseMember` performs full parsing and `PathUnescape` on the entire member without any size guard, amplifying work for large inputs. `Parse` no longer checks bStr length and continues processing invalid members, so oversized/invalid headers are fully parsed instead of being rejected early.\n- In `propagation/baggage.go`, parsing errors from attacker-controlled headers are sent to the global error handler (default logging), which can amplify oversized-input impact.\n\n### PoC\n\n[baggage_dos_poc.tar.gz](https://github.com/user-attachments/files/26677819/baggage_dos_poc.tar.gz)\n\n### Impact\n\nThe issue is reachable through standard propagation parsing (in-scope) and can be exploited remotely to cause CPU/log amplification, but the impact is availability-only and bounded by transport header limits and configurable error handling, supporting a medium severity rather than high/critical.\n\n`baggage.Parse` iterates over all list members with `strings.SplitSeq` and skips invalid members while continuing, without a raw-length guard. `parseMember` performs full parsing and `PathUnescape` on each member, and `propagation.Baggage` forwards parsing errors to the global error handler, which logs by default. A remote client can therefore send oversized/invalid baggage headers that bypass the 8KB limit for valid members, causing extra CPU work and large log output, resulting in availability/log amplification in services that accept large headers and use the default handler.\n\nAssumptions:\n\n- An instrumented service uses the OpenTelemetry baggage propagator for inbound request parsing.\n- Attackers can send oversized or malformed baggage headers that pass the hosting server/proxy header size limits.\n- The default error handler is used or logs are otherwise emitted for parse errors.\n- Inbound request parsing with propagation.Baggage\n- Oversized/invalid baggage headers accepted by the HTTP/gRPC stack\n- Error handler not suppressing parse errors",
  "id": "GHSA-5wrp-cwcj-q835",
  "modified": "2026-06-09T11:53:08Z",
  "published": "2026-05-28T17:04:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-5wrp-cwcj-q835"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41178"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/pull/7880"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-go"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "opentelemetry-go\u0027s baggage parsing no longer caps raw header length"
}

GHSA-5X94-69RX-G8H2

Vulnerability from github – Published: 2026-07-20 21:08 – Updated: 2026-07-20 21:08
VLAI
Summary
Pillow: `FontFile.compile()`: `Image.new()` called without `_decompression_bomb_check()`
Details

Description

PIL/FontFile.py FontFile.compile() assembles per-glyph images into a single combined bitmap using Image.new("1", (xsize, ysize)) without calling Image._decompression_bomb_check(). This is the base-class method shared by both BdfFontFile and PcfFontFile, and it is triggered whenever a loaded font is converted to an ImageFont or saved.

Neither BdfFontFile.BdfFontFile(fp) nor PcfFontFile.PcfFontFile(fp) is registered with Image.register_open(), so Pillow's standard decompression bomb guard never fires for font objects. The compile step is the final opportunity to check the combined allocation — and it has no check.

Vulnerable code (PIL/FontFile.py lines ~64–92):

def compile(self) -> None:
    if self.bitmap:
        return

    h = w = maxwidth = 0
    lines = 1
    for glyph in self.glyph:              # up to 256 glyph slots
        if glyph:
            d, dst, src, im = glyph
            h = max(h, src[3] - src[1])   # max glyph height — attacker-controlled
            w = w + (src[2] - src[0])
            if w > WIDTH:                  # WIDTH = 800
                lines += 1
                w = src[2] - src[0]
            maxwidth = max(maxwidth, w)

    xsize = maxwidth                       # ≤ 800 (capped by WIDTH constant)
    ysize = lines * h                      # ← lines(256) × h(65535) = 16,776,960

    if xsize == 0 and ysize == 0:
        return

    self.ysize = h
    # NO _decompression_bomb_check() here ←
    self.bitmap = Image.new("1", (xsize, ysize))   # ← unchecked allocation

"Slow accumulation" attack — per-glyph dimensions stay BELOW warning threshold:

Metric Per-glyph (800 × 875) Combined bitmap (256 glyphs)
Pixel count 700,000 179,200,000
DecompressionBombWarning threshold (89.4M) 0.008× — no warning 2.0× — above warning
DecompressionBombError threshold (178.9M) 0.004× — no error 1.001× — above error

With PCF-maximum glyph height (65,535):

Metric Value
lines 256 (one per glyph slot, width=800 forces a wrap every glyph)
h (max glyph height) 65,535
xsize 800
ysize = lines × h 256 × 65,535 = 16,776,960
Total pixels 800 × 16,776,960 = 13,421,568,000
Ratio vs. DecompressionBombError threshold 75×
Memory (mode "1", 1 bit/pixel) ~1.6 GB

Steps to reproduce

Proof of Concept script:

#!/usr/bin/env python3
"""
PoC: FontFile.compile() bomb bypass
256 glyphs at 800x875 each (individually below warning threshold)
→ compile() creates 800x224000 = 179.2M px bitmap with NO bomb check
"""
from PIL import FontFile, Image

MAX_GLYPHS = 256
GLYPH_W    = 800
GLYPH_H    = 875     # individual: 700K px — below 89.4M warning threshold

class MockFont(FontFile.FontFile):
    def __init__(self):
        super().__init__()
        # Each glyph is individually safe (700K px < 89.4M warning)
        im = Image.new("1", (GLYPH_W, GLYPH_H))
        for i in range(MAX_GLYPHS):
            self.glyph[i] = (
                (GLYPH_W, GLYPH_H),
                (0, -GLYPH_H, GLYPH_W, 0),
                (0, 0,        GLYPH_W, GLYPH_H),
                im,
            )

# Confirm bomb check WOULD catch the combined size
combined_size = (GLYPH_W, MAX_GLYPHS * GLYPH_H)
try:
    Image._decompression_bomb_check(combined_size)
    print("[FAIL] bomb check did not raise — unexpected")
except Image.DecompressionBombError as e:
    print(f"[OK] bomb check WOULD block {combined_size}: {e}")

# Vulnerable path: compile() has NO bomb check
font = MockFont()
font.compile()   # → Image.new("1", (800, 224000)) — no error raised

px = font.bitmap.size[0] * font.bitmap.size[1]
threshold = Image.MAX_IMAGE_PIXELS * 2
print(f"[BYPASS] compile() succeeded: bitmap={font.bitmap.size}")
print(f"         pixels={px:,}  ({px/threshold:.3f}× DecompressionBombError threshold)")
print(f"         No DecompressionBombError raised at any point.")

Expected output:

[OK] bomb check WOULD block (800, 224000): Image size (179200000 pixels) exceeds limit
of 178956970 pixels, could be decompression bomb DOS attack.
[BYPASS] compile() succeeded: bitmap=(800, 224000)
         pixels=179,200,000  (1.001× DecompressionBombError threshold)
         No DecompressionBombError raised at any point.

Verified live on Pillow 12.2.0 — compile() succeeds with no exception.

Real-world trigger using BDF font file:

from PIL import BdfFontFile
import io

# Load a crafted BDF font with 256 glyphs each claiming height=65535
# (each glyph individually: 800 × 65535 = 52.4M px — below 89.4M warning)
# compile() combined: 800 × 16,776,960 = 13.4B px — 75× error threshold
font = BdfFontFile.BdfFontFile(open("crafted_256glyph.bdf", "rb"))
font.to_imagefont()   # → compile() → ~1.6 GB allocation, NO bomb check

Attack scenarios:

Scenario Effect
Web font preview (BdfFontFile(upload).to_imagefont()) DoS with crafted .bdf upload
Server-side font renderer that loads PCF → to_imagefont() OOM crash
Font pipeline: load → render text One malicious font file kills the process

Impact

  • Availability: HIGH — compile() creates a combined bitmap whose pixel count scales as WIDTH × lines × max_glyph_height with no upper bound check. With max PCF glyph height (65,535) and 256 glyphs, the combined allocation is ~1.6 GB. With BDF (text-format, unbounded height), the allocation is limited only by system memory.
  • Confidentiality: None
  • Integrity: None

Affected call paths: - BdfFontFile.BdfFontFile(fp).to_imagefont() → FontFile.compile() - BdfFontFile.BdfFontFile(fp).save(filename) → FontFile.compile() - PcfFontFile.PcfFontFile(fp).to_imagefont() → FontFile.compile() - PcfFontFile.PcfFontFile(fp).save(filename) → FontFile.compile()

Neither BdfFontFile nor PcfFontFile is loaded via Image.open(), so the standard decompression bomb guard is entirely absent from the font loading code path. compile() is the only point where the combined allocation size is known, and it has no check.

Confirmed unpatched on python-pillow/Pillow main branch as of 2026-06-08.

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": "pillow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54060"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:08:40Z",
    "nvd_published_at": "2026-07-06T19:17:08Z",
    "severity": "HIGH"
  },
  "details": "## Description\n\n`PIL/FontFile.py` `FontFile.compile()` assembles per-glyph images into a single combined bitmap using `Image.new(\"1\", (xsize, ysize))` without calling `Image._decompression_bomb_check()`. This is the base-class method shared by both `BdfFontFile` and `PcfFontFile`, and it is triggered whenever a loaded font is converted to an `ImageFont` or saved.\n\nNeither `BdfFontFile.BdfFontFile(fp)` nor `PcfFontFile.PcfFontFile(fp)` is registered with `Image.register_open()`, so Pillow\u0027s standard decompression bomb guard never fires for font objects. The compile step is the final opportunity to check the combined allocation \u2014 and it has no check.\n\n**Vulnerable code (`PIL/FontFile.py` lines ~64\u201392):**\n\n```python\ndef compile(self) -\u003e None:\n    if self.bitmap:\n        return\n\n    h = w = maxwidth = 0\n    lines = 1\n    for glyph in self.glyph:              # up to 256 glyph slots\n        if glyph:\n            d, dst, src, im = glyph\n            h = max(h, src[3] - src[1])   # max glyph height \u2014 attacker-controlled\n            w = w + (src[2] - src[0])\n            if w \u003e WIDTH:                  # WIDTH = 800\n                lines += 1\n                w = src[2] - src[0]\n            maxwidth = max(maxwidth, w)\n\n    xsize = maxwidth                       # \u2264 800 (capped by WIDTH constant)\n    ysize = lines * h                      # \u2190 lines(256) \u00d7 h(65535) = 16,776,960\n\n    if xsize == 0 and ysize == 0:\n        return\n\n    self.ysize = h\n    # NO _decompression_bomb_check() here \u2190\n    self.bitmap = Image.new(\"1\", (xsize, ysize))   # \u2190 unchecked allocation\n```\n\n**\"Slow accumulation\" attack \u2014 per-glyph dimensions stay BELOW warning threshold:**\n\n| Metric | Per-glyph (800 \u00d7 875) | Combined bitmap (256 glyphs) |\n|---|---|---|\n| Pixel count | 700,000 | **179,200,000** |\n| DecompressionBombWarning threshold (89.4M) | 0.008\u00d7 \u2014 **no warning** | 2.0\u00d7 \u2014 above warning |\n| DecompressionBombError threshold (178.9M) | 0.004\u00d7 \u2014 **no error** | **1.001\u00d7 \u2014 above error** |\n\nWith PCF-maximum glyph height (65,535):\n\n| Metric | Value |\n|---|---|\n| lines | 256 (one per glyph slot, width=800 forces a wrap every glyph) |\n| h (max glyph height) | 65,535 |\n| xsize | 800 |\n| ysize = lines \u00d7 h | 256 \u00d7 65,535 = **16,776,960** |\n| **Total pixels** | 800 \u00d7 16,776,960 = **13,421,568,000** |\n| **Ratio vs. DecompressionBombError threshold** | **75\u00d7** |\n| Memory (mode \"1\", 1 bit/pixel) | **~1.6 GB** |\n\n## Steps to reproduce\n\n**Proof of Concept script:**\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC: FontFile.compile() bomb bypass\n256 glyphs at 800x875 each (individually below warning threshold)\n\u2192 compile() creates 800x224000 = 179.2M px bitmap with NO bomb check\n\"\"\"\nfrom PIL import FontFile, Image\n\nMAX_GLYPHS = 256\nGLYPH_W    = 800\nGLYPH_H    = 875     # individual: 700K px \u2014 below 89.4M warning threshold\n\nclass MockFont(FontFile.FontFile):\n    def __init__(self):\n        super().__init__()\n        # Each glyph is individually safe (700K px \u003c 89.4M warning)\n        im = Image.new(\"1\", (GLYPH_W, GLYPH_H))\n        for i in range(MAX_GLYPHS):\n            self.glyph[i] = (\n                (GLYPH_W, GLYPH_H),\n                (0, -GLYPH_H, GLYPH_W, 0),\n                (0, 0,        GLYPH_W, GLYPH_H),\n                im,\n            )\n\n# Confirm bomb check WOULD catch the combined size\ncombined_size = (GLYPH_W, MAX_GLYPHS * GLYPH_H)\ntry:\n    Image._decompression_bomb_check(combined_size)\n    print(\"[FAIL] bomb check did not raise \u2014 unexpected\")\nexcept Image.DecompressionBombError as e:\n    print(f\"[OK] bomb check WOULD block {combined_size}: {e}\")\n\n# Vulnerable path: compile() has NO bomb check\nfont = MockFont()\nfont.compile()   # \u2192 Image.new(\"1\", (800, 224000)) \u2014 no error raised\n\npx = font.bitmap.size[0] * font.bitmap.size[1]\nthreshold = Image.MAX_IMAGE_PIXELS * 2\nprint(f\"[BYPASS] compile() succeeded: bitmap={font.bitmap.size}\")\nprint(f\"         pixels={px:,}  ({px/threshold:.3f}\u00d7 DecompressionBombError threshold)\")\nprint(f\"         No DecompressionBombError raised at any point.\")\n```\n\n**Expected output:**\n```\n[OK] bomb check WOULD block (800, 224000): Image size (179200000 pixels) exceeds limit\nof 178956970 pixels, could be decompression bomb DOS attack.\n[BYPASS] compile() succeeded: bitmap=(800, 224000)\n         pixels=179,200,000  (1.001\u00d7 DecompressionBombError threshold)\n         No DecompressionBombError raised at any point.\n```\n\n**Verified live on Pillow 12.2.0 \u2014 compile() succeeds with no exception.**\n\n**Real-world trigger using BDF font file:**\n```python\nfrom PIL import BdfFontFile\nimport io\n\n# Load a crafted BDF font with 256 glyphs each claiming height=65535\n# (each glyph individually: 800 \u00d7 65535 = 52.4M px \u2014 below 89.4M warning)\n# compile() combined: 800 \u00d7 16,776,960 = 13.4B px \u2014 75\u00d7 error threshold\nfont = BdfFontFile.BdfFontFile(open(\"crafted_256glyph.bdf\", \"rb\"))\nfont.to_imagefont()   # \u2192 compile() \u2192 ~1.6 GB allocation, NO bomb check\n```\n\n**Attack scenarios:**\n\n| Scenario | Effect |\n|---|---|\n| Web font preview (`BdfFontFile(upload).to_imagefont()`) | DoS with crafted .bdf upload |\n| Server-side font renderer that loads PCF \u2192 `to_imagefont()` | OOM crash |\n| Font pipeline: load \u2192 render text | One malicious font file kills the process |\n\n## Impact\n\n- **Availability:** HIGH \u2014 `compile()` creates a combined bitmap whose pixel count scales as `WIDTH \u00d7 lines \u00d7 max_glyph_height` with no upper bound check. With max PCF glyph height (65,535) and 256 glyphs, the combined allocation is ~1.6 GB. With BDF (text-format, unbounded height), the allocation is limited only by system memory.\n- **Confidentiality:** None\n- **Integrity:** None\n\n**Affected call paths:**\n- `BdfFontFile.BdfFontFile(fp).to_imagefont()` \u2192 `FontFile.compile()`\n- `BdfFontFile.BdfFontFile(fp).save(filename)` \u2192 `FontFile.compile()`\n- `PcfFontFile.PcfFontFile(fp).to_imagefont()` \u2192 `FontFile.compile()`\n- `PcfFontFile.PcfFontFile(fp).save(filename)` \u2192 `FontFile.compile()`\n\nNeither `BdfFontFile` nor `PcfFontFile` is loaded via `Image.open()`, so the standard decompression bomb guard is **entirely absent** from the font loading code path. `compile()` is the only point where the combined allocation size is known, and it has no check.\n\nConfirmed unpatched on `python-pillow/Pillow` `main` branch as of 2026-06-08.",
  "id": "GHSA-5x94-69rx-g8h2",
  "modified": "2026-07-20T21:08:40Z",
  "published": "2026-07-20T21:08:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-5x94-69rx-g8h2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54060"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/commit/0a263e6264aa5399988d9acd3bbfbca2ca3ec77d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2026-2254.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-pillow/Pillow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/blob/main/docs/releasenotes/12.3.0.rst"
    }
  ],
  "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": "Pillow: `FontFile.compile()`: `Image.new()` called without `_decompression_bomb_check()`"
}

GHSA-655V-G44J-4FC7

Vulnerability from github – Published: 2024-11-23 03:31 – Updated: 2024-11-23 03:31
VLAI
Details

IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 10.5, 11.1, and 11.5 is vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-41761"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-23T03:15:08Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 10.5, 11.1, and 11.5 is vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query.",
  "id": "GHSA-655v-g44j-4fc7",
  "modified": "2024-11-23T03:31:59Z",
  "published": "2024-11-23T03:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41761"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7175947"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-659W-93R5-9J6M

Vulnerability from github – Published: 2026-05-04 18:30 – Updated: 2026-05-08 17:54
VLAI
Summary
Apache OpenNLP AbstractModelReader has an OOM Denial of Service via Unbounded Array Allocation
Details

OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader 

Versions Affected: 

Before 2.5.9

Before 3.0.0-M3 

Description:

The AbstractModelReader methods getOutcomes(), getOutcomePatterns(), and getPredicates() each read a 32-bit signed integer count field from a binary model stream and pass that value directly to an array allocation (new String[numOutcomes], new int[numOCTypes][], new String[NUM_PREDS]) without validating that the value is non-negative or within a reasonable bound. The count is therefore fully attacker-controlled when the model file originates from an untrusted source.

A crafted .bin model file in which any of these count fields is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) triggers an OutOfMemoryError at the array allocation itself, before the corresponding label or pattern data is consumed from the stream. The error occurs very early in deserialization: for a GIS model, getOutcomes() is reached after only the model-type string, the correction constant, and the correction parameter have been read; so the attacker pays no meaningful size cost to weaponize a payload, and a single small file can crash a JVM that loads it. Any code path that deserializes a .bin model is affected, including direct use of GenericModelReader and any higher-level component that delegates to it during model load.

The practical impact is denial of service against processes that load model files from untrusted or semi-trusted origins.  

Mitigation:

  • 2.x users should upgrade to 2.5.9.

  • 3.x users should upgrade to 3.0.0-M3.

Note: The fix introduces an upper bound on each of the three count fields, checked before array allocation; counts that are negative or exceed the bound cause an IllegalArgumentException to be thrown and the read to fail fast with no large allocation. The default bound is 10,000,000, which is well above the entry counts of legitimate OpenNLP models but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load models with more entries than the default can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default.

Users who cannot upgrade immediately should treat all .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.

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": "Maven",
        "name": "org.apache.opennlp:opennlp-tools"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.opennlp:opennlp-tools"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-M1"
            },
            {
              "fixed": "3.0.0-M3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T17:54:23Z",
    "nvd_published_at": "2026-05-04T17:16:26Z",
    "severity": "HIGH"
  },
  "details": "OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader\u00a0\n\nVersions Affected:\u00a0\n\nBefore 2.5.9\n\nBefore 3.0.0-M3\u00a0\n\nDescription:\n\n\nThe AbstractModelReader methods getOutcomes(), getOutcomePatterns(), and getPredicates() each read a 32-bit signed integer count field from a binary model stream and pass that value directly to an array allocation (new String[numOutcomes], new int[numOCTypes][], new String[NUM_PREDS]) without validating that the value is non-negative or within a reasonable bound. The count is therefore fully attacker-controlled when the model file originates from an untrusted source.\n\n\nA crafted .bin model file in which any of these count fields is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) triggers an OutOfMemoryError at the array allocation itself, before the corresponding label or pattern data is consumed from the stream. The error occurs very early in deserialization: for a GIS model, getOutcomes() is reached after only the model-type string, the correction constant, and the correction parameter have been read; so the attacker pays no meaningful size cost to weaponize a payload, and a single small file can crash a JVM that loads it. Any code path that deserializes a .bin model is affected, including direct use of GenericModelReader and any higher-level component that delegates to it during model load.\n\n\nThe practical impact is denial of service against processes that load model files from untrusted or semi-trusted origins.\u00a0\u00a0\n\n\nMitigation:\n\n\n\n  *  2.x users should upgrade to 2.5.9.\n\n  *  3.x users should upgrade to 3.0.0-M3.\n\n\n\n\nNote: The fix introduces an upper bound on each of the three count fields, checked before array allocation; counts that are negative or exceed the bound cause an IllegalArgumentException to be thrown and the read to fail fast with no large allocation. The default bound is 10,000,000, which is well above the entry counts of legitimate OpenNLP models but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load models with more entries than the default can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default.\n\n\nUsers who cannot upgrade immediately should treat all .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.",
  "id": "GHSA-659w-93r5-9j6m",
  "modified": "2026-05-08T17:54:23Z",
  "published": "2026-05-04T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42440"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/opennlp"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/s8xlkx1gqbxfsq48py5h6jphjvgqp1jo"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/01/21"
    }
  ],
  "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": "Apache OpenNLP AbstractModelReader has an OOM Denial of Service via Unbounded Array Allocation"
}

GHSA-65H2-WF7M-Q2V8

Vulnerability from github – Published: 2023-09-27 15:30 – Updated: 2024-05-03 20:27
VLAI
Summary
Undertow vulnerable to denial of service
Details

A flaw was found in undertow. Servlets annotated with @MultipartConfig may cause an OutOfMemoryError due to large multipart content. This may allow unauthorized users to cause remote Denial of Service (DoS) attack. If the server uses fileSizeThreshold to limit the file size, it's possible to bypass the limit by setting the file name in the request to null.

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": "Maven",
        "name": "io.undertow:undertow-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.24.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-3223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-27T20:16:42Z",
    "nvd_published_at": "2023-09-27T15:18:56Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in undertow. Servlets annotated with @MultipartConfig may cause an OutOfMemoryError due to large multipart content. This may allow unauthorized users to cause remote Denial of Service (DoS) attack. If the server uses fileSizeThreshold to limit the file size, it\u0027s possible to bypass the limit by setting the file name in the request to null.",
  "id": "GHSA-65h2-wf7m-q2v8",
  "modified": "2024-05-03T20:27:47Z",
  "published": "2023-09-27T15:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3223"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4505"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4506"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4507"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4509"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4918"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4919"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4920"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4921"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4924"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7247"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-3223"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2209689"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/undertow-io/undertow"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231027-0004"
    }
  ],
  "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": "Undertow vulnerable to denial of service"
}

GHSA-68MJ-5WR7-6FGG

Vulnerability from github – Published: 2026-08-18 16:32 – Updated: 2026-08-18 16:32
VLAI
Summary
RabbitMQ Java client ValueReader: Oversized LongString/bytes length triggers OOM via unchecked allocation
Details

Summary

ValueReader.readBytes() allocates a byte array sized by a wire-declared content length without validating it against actual frame data. A malicious AMQP peer triggers OOM by declaring a ~2GB string/bytes field.

Vulnerable Code

src/main/java/com/rabbitmq/client/impl/ValueReader.java lines 83-95:

private static byte[] readBytes(final DataInputStream in) throws IOException {
    final long contentLength = unsignedExtend(in.readInt());
    if(contentLength < Integer.MAX_VALUE) {
        final byte[] buffer = new byte[(int)contentLength];  // allocates before reading
        in.readFully(buffer);
        return buffer;
    }
}

Attack Scenario

A malicious AMQP server sends a LongString field (type tag 'S') with declared length 0x7FFFFFFE (2,147,483,646). The check contentLength < Integer.MAX_VALUE passes. new byte[2147483646] attempts ~2GB allocation, causing OutOfMemoryError before readFully() attempts to read data.

The allocation size is attacker-controlled and is NOT validated against the frame size or TruncatedInputStream bounds. Exploitable pre-authentication via connection.start server-properties table.

Impact

Denial of service via JVM OutOfMemoryError. Crashes the entire JVM.

CWE

CWE-789: Memory Allocation with Excessive Size Value

Remediation

Validate contentLength against the frame's remaining bytes or the negotiated max frame size (default 131,072) before allocating.

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
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.33.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.rabbitmq:amqp-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.33.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T16:32:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`ValueReader.readBytes()` allocates a byte array sized by a wire-declared content length without validating it against actual frame data. A malicious AMQP peer triggers OOM by declaring a ~2GB string/bytes field.\n\n## Vulnerable Code\n\n`src/main/java/com/rabbitmq/client/impl/ValueReader.java` lines 83-95:\n\n```java\nprivate static byte[] readBytes(final DataInputStream in) throws IOException {\n    final long contentLength = unsignedExtend(in.readInt());\n    if(contentLength \u003c Integer.MAX_VALUE) {\n        final byte[] buffer = new byte[(int)contentLength];  // allocates before reading\n        in.readFully(buffer);\n        return buffer;\n    }\n}\n```\n\n## Attack Scenario\n\nA malicious AMQP server sends a LongString field (type tag \u0027S\u0027) with declared length `0x7FFFFFFE` (2,147,483,646). The check `contentLength \u003c Integer.MAX_VALUE` passes. `new byte[2147483646]` attempts ~2GB allocation, causing `OutOfMemoryError` before `readFully()` attempts to read data.\n\nThe allocation size is attacker-controlled and is NOT validated against the frame size or `TruncatedInputStream` bounds. Exploitable pre-authentication via `connection.start` server-properties table.\n\n## Impact\n\nDenial of service via JVM `OutOfMemoryError`. Crashes the entire JVM.\n\n## CWE\n\nCWE-789: Memory Allocation with Excessive Size Value\n\n## Remediation\n\nValidate `contentLength` against the frame\u0027s remaining bytes or the negotiated max frame size (default 131,072) before allocating.",
  "id": "GHSA-68mj-5wr7-6fgg",
  "modified": "2026-08-18T16:32:21Z",
  "published": "2026-08-18T16:32:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-68mj-5wr7-6fgg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2007"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2008"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/388209356c6478088efce4d8a07b68e73837a7a0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/6a87a8dcdc8b4cc4b961a7cdd388276446e5dfb2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.33.1"
    }
  ],
  "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": "RabbitMQ Java client ValueReader: Oversized LongString/bytes length triggers OOM via unchecked allocation"
}

GHSA-6JP5-GRGH-JW42

Vulnerability from github – Published: 2026-02-04 20:47 – Updated: 2026-02-04 20:47
VLAI
Summary
EVE Freely Allocates Buffer on The Stack With Data From Socket
Details

Impact

VTPM server listens on port 8877, exposing limited TPM functionality. The server reads 4 bytes as a uint32 size header, then allocates that amount on the stack for incoming data. This allows Denial of Service attacks against the vTPM service.

An workload (a container or VM) running on EVE-OS can use this to generate a DOS against the vTPM service.

Patches

Fixed in 9.4.3-lts and 10.1.0

Workarounds

None

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lf-edge/eve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20230519072751-977f42b07fa9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-43632"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-04T20:47:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nVTPM server listens on port 8877, exposing limited TPM functionality. The server reads 4 bytes as a uint32 size header, then allocates that amount on the stack for incoming data. This allows Denial of Service attacks against the vTPM service.\n\nAn workload (a container or VM) running on EVE-OS can use this to generate a DOS against the vTPM service.\n\n### Patches\n\nFixed in 9.4.3-lts and 10.1.0\n\n### Workarounds\n\nNone",
  "id": "GHSA-6jp5-grgh-jw42",
  "modified": "2026-02-04T20:47:37Z",
  "published": "2026-02-04T20:47:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lf-edge/eve/security/advisories/GHSA-6jp5-grgh-jw42"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43632"
    },
    {
      "type": "WEB",
      "url": "https://asrg.io/security-advisories/cve-2023-43632"
    },
    {
      "type": "WEB",
      "url": "https://asrg.io/security-advisories/freely-allocate-buffer-on-the-stack-with-data-from-socket"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lf-edge/eve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "EVE Freely Allocates Buffer on The Stack With Data From Socket"
}

GHSA-6MC8-MX43-H2QW

Vulnerability from github – Published: 2026-08-05 09:31 – Updated: 2026-08-05 09:31
VLAI
Details

imagecli's scale <ratio> pipeline operation (Scale::apply() in src/image_ops.rs) computes output width/height as (dimension as f32 * ratio) as u32 with no upper-bound validation on the CLI-supplied ratio, which is parsed via nom::number::complete::float with no range check. A large ratio (e.g. 100000) causes an attempted allocation of hundreds of terabytes, aborting the process. Any application embedding imagecli as a library and accepting user-controlled pipeline strings is remotely crashable with a single request.

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": [],
  "aliases": [
    "CVE-2026-70377"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T08:16:41Z",
    "severity": "HIGH"
  },
  "details": "imagecli\u0027s `scale \u003cratio\u003e` pipeline operation (Scale::apply() in src/image_ops.rs) computes output width/height as (dimension as f32 * ratio) as u32 with no upper-bound validation on the CLI-supplied ratio, which is parsed via nom::number::complete::float with no range check. A large ratio (e.g. 100000) causes an attempted allocation of hundreds of terabytes, aborting the process. Any application embedding imagecli as a library and accepting user-controlled pipeline strings is remotely crashable with a single request.",
  "id": "GHSA-6mc8-mx43-h2qw",
  "modified": "2026-08-05T09:31:18Z",
  "published": "2026-08-05T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70377"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theotherphil/imagecli/issues/66"
    }
  ],
  "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-6MGC-4427-8P4X

Vulnerability from github – Published: 2026-03-17 21:31 – Updated: 2026-04-27 18:32
VLAI
Details

dr_libs version 0.13.3 and earlier contain an uncontrolled memory allocation vulnerability in drflac__read_and_decode_metadata() that allows attackers to trigger excessive memory allocation by supplying crafted PICTURE metadata blocks. Attackers can exploit attacker-controlled mimeLength and descriptionLength fields to cause denial of service through memory exhaustion when processing FLAC streams with metadata callbacks.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
6.9 (Medium)
CVSS:4.0/AV:L/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": [],
  "aliases": [
    "CVE-2026-32836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-17T20:16:14Z",
    "severity": "MODERATE"
  },
  "details": "dr_libs version 0.13.3 and earlier contain an uncontrolled memory allocation vulnerability in drflac__read_and_decode_metadata() that allows attackers to trigger excessive memory allocation by supplying crafted PICTURE metadata blocks. Attackers can exploit attacker-controlled mimeLength and descriptionLength fields to cause denial of service through memory exhaustion when processing FLAC streams with metadata callbacks.",
  "id": "GHSA-6mgc-4427-8p4x",
  "modified": "2026-04-27T18:32:01Z",
  "published": "2026-03-17T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32836"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mackron/dr_libs/issues/298"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mackron/dr_libs/commit/4f5a4cd3b57564d969443c580c75857e039f100a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mackron/dr_libs/commit/663239a3d0460c33bd5b6e5166edcb404e3df676"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mackron/dr_libs/commit/fefced4a64adfb1a68a2d31d882366e56096dee8"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/mackron-dr-libs-excessive-memory-allocation-in-picture-metadata-parsing"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/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"
    }
  ]
}
Mitigation
Implementation Architecture and Design

Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.

Mitigation
Operation

Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list