CVE-2026-107391 is a medium severity denial of service (CVSS 6.2) in music-metadata. An MP4 stsd parsing regression could block the Node.js event loop. The advisory says it was only on the public development branch, never in an npm release up to 11.14.0. Version 11.16.0 contains the fix.
What's affected
This one is narrow, so read it carefully. The record says the vulnerable change was present on the public master branch after 11.14.0 but was not included in music-metadata 11.14.0 or any earlier npm release, and that 11.16.0 contains the fix. The GitHub advisory GHSA-f94x-6692-553q, published on 23 September 2026, agrees. It lists the affected version as a specific commit and describes the issue as an unreleased regression on master, with a patched version of 11.16.0.
Put plainly: if you install music-metadata from npm at 11.14.0 or earlier, this CVE does not apply to you according to both sources. If you build from the master branch, install from a git commit, or run a fork that tracks master during the window the advisory describes, check your revision.
The weaknesses are CWE-400, uncontrolled resource consumption, and CWE-835, a loop whose exit is unreachable. The vector is local, low complexity, no privileges, availability only.
How to check if you're exposed
Check how you consume the package:
npm ls music-metadata
grep -n "music-metadata" package.json package-lock.json
If the version is an ordinary npm release number, you are outside the scope the advisory describes, because no npm release carried the change. If the entry in package.json points to a git URL, a branch name or a commit hash, you may have taken the unreleased code. In that case compare the commit with the advisory and move to 11.16.0.
Also check vendored copies and forks, which do not show up in npm ls under the original name.
What to do now
- Check whether any project installs music-metadata from git or from a branch, and if so move it to a released version.
- Upgrade to 11.16.0 or later where you want the fix and the other repairs it carries.
- Do not run applications against a development branch of a parser that handles untrusted files.
- Keep untrusted media parsing in a separate worker with a timeout, so a loop in a parser cannot freeze your main service.
- Record in your inventory whether each dependency comes from a registry release or from a source branch.
Why it matters
The regression came from a fix for a different bug. A change corrected how the parser finds each sample entry in the stsd box, and as a side effect an entry size of zero made the cursor stop moving while an attacker controlled entry count kept the loop going. Because the code ran synchronously inside the tokenizer, nothing yielded back to the event loop, so the whole Node.js process stopped serving anyone until it was killed or ran out of memory.
The pattern is worth remembering: a fix that adjusts an offset can create a new loop that never advances. Any loop over input should confirm progress on each pass, and a size field of zero is the classic way to defeat it.
There is also a lesson about advisories. A CVE can exist for code that never shipped. The honest answer for most users is that it does not affect them, and a good inventory is what lets you give that answer quickly. The record does not mark this CVE as known exploited.
Quick check
Do I need to patch if I use npm 11.14.0?
Both the record and the advisory say the vulnerable change was not in 11.14.0 or any earlier npm release.
What should source builders do?
Compare your revision with the advisory and move to 11.16.0 or later.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
