CVE-2026-107389: music-metadata EBML Parser Trusts Element Lengths, Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-5gfj-9q3v-qfp3",
  "modified" : "2026-10-08T19:43:09Z",
  "published" : "2026-10-08T19:43:09Z",
  "aliases" : [ "CVE-2026-107389" ],
  "summary" : "music-metadata: EBML parser trusts element lengths, allowing memory exhaustion or process abort",
  "details" : "## Summary\n\nThe Matroska/WebM EBML parser decodes attacker-controlled variable-length integer (VINT) element lengths without first validating that the declared element fits within its enclosing container or the available input. Leaf lengths are then used directly for string-token and `Uint8Array` allocations.\n\nA very small crafted `.webm`, `.mkv`, or `.mka` file can therefore cause a disproportionately large allocation, an out-of-memory denial of service, or—in one demonstrated `parseFile` case—an uncatchable V8 fatal abort.\n\n## Impact\n\nApplications that parse untrusted Matroska/WebM media can be denied service. Depending on the input, parser API, and Node.js/V8 version, the demonstrated outcomes include:\n\n- a 34-byte input causing an approximately 128 MiB allocation before end-of-input;\n- a 70-byte input causing a 500 MiB allocation through a binary EBML leaf, with concurrent parses multiplying memory consumption;\n- a 48-byte file causing an uncatchable V8 fatal abort through `parseFile` when a leaf declares a length of 32 GiB.\n\nThe fatal-abort case was reproduced on `music-metadata` 11.15.0 with Node.js 26.7.0. It was deterministic across three runs and exited with code 133 despite a surrounding `try`/`catch`. The same reporter did not reproduce that fatal abort through `parseBuffer` on Node.js 20 through 25; those configurations can still encounter allocation attempts or catchable errors. The exact failure mode is therefore runtime- and tokenizer-dependent, but the underlying validation flaw is shared.\n\nThe impact is limited to availability; no confidentiality or integrity impact has been demonstrated.\n\n## Root cause\n\n`EbmlIterator.readElement()` decodes an element length from an EBML VINT and converts it to a JavaScript `Number`:\n\n```ts\nprivate async readElement(): Promise<IHeader> {\n  const id = await this.readVintData(this.ebmlMaxIDLength);\n  const lenField = await this.readVintData(this.ebmlMaxSizeLength);\n  lenField[0] ^= 0x80 >> (lenField.length - 1);\n  return {\n    id: readUIntBE(id, id.length),\n    len: readUIntBE(lenField, lenField.length)\n  };\n}\n```\n\nBefore the fix, that value was not checked against the parent boundary or known file size before reaching the leaf readers:\n\n```ts\nprivate async readString(e: IHeader): Promise<string> {\n  const rawString = await this.tokenizer.readToken(new StringType(e.len, 'utf-8'));\n  return rawString.replace(/\\x00.*$/g, '');\n}\n\nprivate async readBuffer(e: IHeader): Promise<Uint8Array> {\n  const buf = new Uint8Array(e.len);\n  await this.tokenizer.readBuffer(buf);\n  return buf;\n}\n```\n\nAn EBML size VINT can encode values approaching 2^56. A crafted file can select a known string, unsigned-integer, binary, or UID element and route its declared size into an allocation before the tokenizer discovers that the input is truncated. The declared length also participates in container-boundary arithmetic.\n\nFor lengths around 32 GiB, one reporter observed V8 aborting on its external-memory accounting check:\n\n```text\nFatal error: Check failed: change_in_bytes < kMaxReasonableBytes\nprocess exit code 133\n```\n\nThis is a V8 process abort rather than a JavaScript exception, so application-level error handling cannot catch it.\n\n## Attack scenarios\n\nThe issue is reachable through ordinary metadata parsing of attacker-controlled Matroska/WebM files. Reported proofs of concept exercised string, unsigned-integer, binary, and UID leaves. Depending on the tokenizer and runtime, affected entry points include `parseBuffer`, `parseFile`, `parseStream`, `parseBlob`, and `parseWebStream`.\n\nOne minimal buffer-based proof of concept uses a `docType` string with an oversized eight-byte VINT:\n\n```js\nimport { parseBuffer } from 'music-metadata';\n\nconst payload = Uint8Array.from([\n  0x1a, 0x45, 0xdf, 0xa3, 0x8a,\n  0x42, 0x82,\n  0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff\n]);\n\nawait parseBuffer(payload, { mimeType: 'video/webm' });\n```\n\nAnother proof of concept used a valid WebM EBML header followed by an `ebmlReadVersion` leaf whose VINT declared `0x800000000` bytes (32 GiB), while supplying only one payload byte. Through `parseFile`, this reached the fatal V8 abort described above.\n\n## Fix\n\n[PR #2735](https://github.com/Borewit/music-metadata/pull/2735) validates EBML leaf lengths before decoding or allocating. It rejects lengths that are unsafe, exceed the enclosing container, or exceed the known remaining file data. For streams whose total size is unknown, large leaves are read incrementally so truncated input fails before one large allocation is attempted. Nested-container boundaries are also constrained by ancestor and file boundaries.\n\nAt the time this advisory was updated, PR #2735 was still open and no patched release had been published.\n\n## Credits\n\nThis advisory consolidates independent reports of the same EBML length-validation flaw:\n\n- [@bg0d-glitch](https://github.com/bg0d-glitch) reported oversized VINT lengths reaching string and binary allocation paths.\n- [@Zwique](https://github.com/Zwique) demonstrated approximately 128 MiB of allocation from a 34-byte EBML input as part of a broader parser review.\n- [@offset](https://github.com/offset) demonstrated a 500 MiB allocation from a 70-byte binary-leaf input and the effect of concurrent parses.\n- [@arpitjain099](https://github.com/arpitjain099) demonstrated the 48-byte `parseFile` case that triggers an uncatchable V8 fatal abort.\n\nThe reports were consolidated because they share the same vulnerable component, missing validation, allocation sinks, and fix.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "music-metadata"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "11.16.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Borewit/music-metadata/security/advisories/GHSA-5gfj-9q3v-qfp3"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Borewit/music-metadata/pull/2735"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Borewit/music-metadata/commit/163f013364ac9fc8dd0c3987433cd065a615af58"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Borewit/music-metadata/commit/2d14dc1f7391a94235948a0b823155538f69b3df"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Borewit/music-metadata"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-789" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-08T19:43:09Z",
    "nvd_published_at" : null
  }
}