Skip to content
Heist/ feed
Back to feed
MediumFix available

music-metadata: ID3v2 tag size not validated before allocation, causing memory exhaustion DoS

Type: advisorySources: OSV

### 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 ```typescript // 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

Products
music-metadata
Affected versions
Not specified
Fixed versions
11.16.0
CVEs
CVE-2026-107388
Confirmed fixed CVEs
Not specified
Updated in this feed
28 Oct 2026, 10:04 UTC · Revision 1

Source evidence

music-metadata: ID3v2 tag size not validated before allocation, causing memory exhaustion DoS

core-osv · Original source

Published 8 Oct 2026, 19:43 UTC

### 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 ```typescript // 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

osv:GHSA-jjpr-9cvf-cq55

music-metadata

Fixed versions: 11.16.0

Complete source record
{
  "id": "0ee15c7d5ad5715e0ba61f6006a6408521bcf176988c0a9dd842219e257ca7e0",
  "url": "https://osv.dev/vulnerability/GHSA-jjpr-9cvf-cq55",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "music-metadata: ID3v2 tag size not validated before allocation, causing memory exhaustion DoS",
    "summary": "### 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 ```typescript // 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",
    "evidence": "osv:GHSA-jjpr-9cvf-cq55",
    "products": [
      {
        "name": {
          "value": "music-metadata",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "11.16.0",
            "evidence": "/affected/0/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "medium",
    "structured": {
      "id": "GHSA-jjpr-9cvf-cq55",
      "aliases": [
        "CVE-2026-107388",
        "GHSA-jjpr-9cvf-cq55"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "SEMVER",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "fixed": "11.16.0"
                }
              ]
            }
          ],
          "package": {
            "name": "music-metadata",
            "purl": "pkg:npm/music-metadata",
            "ecosystem": "npm"
          },
          "database_specific": {
            "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-jjpr-9cvf-cq55/GHSA-jjpr-9cvf-cq55.json",
            "last_known_affected_version_range": "<= 11.12.3"
          }
        }
      ],
      "modified": "2026-10-08T20:00:05.873072048Z",
      "provider": "osv",
      "references": [
        "https://github.com/Borewit/music-metadata/security/advisories/GHSA-jjpr-9cvf-cq55",
        "https://github.com/Borewit/music-metadata/pull/2743",
        "https://github.com/Borewit/music-metadata/commit/b033db675b913a9dba1d29135ec3c10eae7095a7",
        "https://github.com/Borewit/music-metadata",
        "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-789"
        ],
        "severity": "MODERATE",
        "github_reviewed": true,
        "nvd_published_at": null,
        "github_reviewed_at": "2026-10-08T19:43:17Z"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-107388",
        "evidence": "/aliases"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 104573,
  "published_at": "2026-10-08T19:43:17+00:00"
}