music-metadata: EBML parser trusts element lengths, allowing memory exhaustion or process abort

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

music-metadata is a metadata parser for audio and video media files. Prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only. This issue is fixed in version 11.16.0.

Source published

8 Oct 2026 19:05:23 UTC

Source modified

9 Oct 2026 18:32:42 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 6.2 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

music-metadata is a metadata parser for audio and video media files. Prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only. This issue is fixed in version 11.16.0.

Source published

Oct 8, 2026, 7:05:23 PM (timezone not stated)

Source modified

Oct 9, 2026, 6:32:42 PM (timezone not stated)

Observed here

7 Nov 2026 04:31:24 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 6.2 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

music-metadata is a metadata parser for audio and video media files. Prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only. This issue is fixed in version 11.16.0.

Source published

8 Oct 2026 20:17:33 UTC

Source modified

21 Oct 2026 15:34:25 UTC

Observed here

25 Oct 2026 05:17:13 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 6.2 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVSS 3.1 · [email protected] · Primary · 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

## Summary The 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. A 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. ## Impact Applications 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: - a 34-byte input causing an approximately 128 MiB allocation before end-of-input; - a 70-byte input causing a 500 MiB allocation through a binary EBML leaf, with concurrent parses multiplying memory consumption; - a 48-byte file causing an uncatchable V8 fatal abort through `parseFile` when a leaf declares a length of 32 GiB. The 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. The impact is limited to availability; no confidentiality or integrity impact has been demonstrated. ## Root cause `EbmlIterator.readElement()` decodes an element length from an EBML VINT and converts it to a JavaScript `Number`: ```ts private async readElement(): Promise<IHeader> { const id = await this.readVintData(this.ebmlMaxIDLength); const lenField = await this.readVintData(this.ebmlMaxSizeLength); lenField[0] ^= 0x80 >> (lenField.length - 1); return { id: readUIntBE(id, id.length), len: readUIntBE(lenField, lenField.length) }; } ``` Before the fix, that value was not checked against the parent boundary or known file size before reaching the leaf readers: ```ts private async readString(e: IHeader): Promise<string> { const rawString = await this.tokenizer.readToken(new StringType(e.len, 'utf-8')); return rawString.replace(/\x00.*$/g, ''); } private async readBuffer(e: IHeader): Promise<Uint8Array> { const buf = new Uint8Array(e.len); await this.tokenizer.readBuffer(buf); return buf; } ``` An 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. For lengths around 32 GiB, one reporter observed V8 aborting on its external-memory accounting check: ```text Fatal error: Check failed: change_in_bytes < kMaxReasonableBytes process exit code 133 ``` This is a V8 process abort rather than a JavaScript exception, so application-level error handling cannot catch it. ## Attack scenarios The 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`. One minimal buffer-based proof of concept uses a `docType` string with an oversized eight-byte VINT: ```js import { parseBuffer } from 'music-metadata'; const payload = Uint8Array.from([ 0x1a, 0x45, 0xdf, 0xa3, 0x8a, 0x42, 0x82, 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff ]); await parseBuffer(payload, { mimeType: 'video/webm' }); ``` Another 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. ## Fix [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. At the time this advisory was updated, PR #2735 was still open and no patched release had been published. ## Credits This advisory consolidates independent reports of the same EBML length-validation flaw: - [@bg0d-glitch](https://github.com/bg0d-glitch) reported oversized VINT lengths reaching string and binary allocation paths. - [@Zwique](https://github.com/Zwique) demonstrated approximately 128 MiB of allocation from a 34-byte EBML input as part of a broader parser review. - [@offset](https://github.com/offset) demonstrated a 500 MiB allocation from a 70-byte binary-leaf input and the effect of concurrent parses. - [@arpitjain099](https://github.com/arpitjain099) demonstrated the 48-byte `parseFile` case that triggers an uncatchable V8 fatal abort. The reports were consolidated because they share the same vulnerable component, missing validation, allocation sinks, and fix.

Source published

8 Oct 2026 19:43:09 UTC

Source modified

8 Oct 2026 20:00:05 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Publisher rating · MODERATE