CVE-2026-107390 is a medium severity denial of service (CVSS 6.2) in the npm package music-metadata. Its MP4 parser trusts an oversized atom length, so a tiny crafted file can crash a Node.js process. It is fixed in 11.16.0, so upgrade to that version or later.
What's affected
The record says versions before 11.16.0 are affected. The GitHub advisory GHSA-qc8q-pw95-mq6c, published on 23 September 2026 and rated Moderate, lists the npm package with affected versions as 11.12.3 and a patched version of 11.16.0. The two sources word the range differently. The record says prior to 11.16.0, and the advisory lists a single affected version. Do not read that as the other versions being safe: the advisory metadata may be incomplete, so treat everything before 11.16.0 as in scope until the project says otherwise.
The weakness is CWE-789, memory allocation with an excessive size value. The vector in the record is local, low complexity, no privileges, with only availability affected, which gives 6.2. The advisory impact statement, however, describes a remote unauthenticated denial of service for applications that parse untrusted MP4 family files.
That is the way to read this: the vector assumes the file is already local to the process, while your service may receive the file over the network from a user.
How to check if you're exposed
Find the installed version, including copies pulled in by other packages:
npm ls music-metadata
yarn why music-metadata
Any version below 11.16.0 needs the upgrade. Because this is a parser library, it often arrives indirectly through media tools, tag editors and upload handlers.
Then ask whether your application parses media from untrusted sources: user uploads, files fetched from URLs, or content from partners. The advisory scopes the risk to applications that parse untrusted MP4 family media. A desktop tool that only reads your own library is much less exposed.
What to do now
- Upgrade music-metadata to 11.16.0 or later and regenerate your lockfile.
- Check for duplicate copies in the dependency tree and make sure every copy is at or above the fixed version.
- Limit upload size and check file type before parsing, and parse in a worker with a memory limit.
- Handle parser failures so one bad file does not end the main process, for example by isolating parsing in a child process.
- Add the package to your inventory so the next advisory is matched automatically.
Why it matters
MP4 files are built from boxes called atoms, and each atom starts with a length. An extended form lets the length be a 64 bit number. According to the advisory, the parser turned that value into a JavaScript number and then used it to size reads, before checking that the atom fit inside its parent or the file. The underlying reader allocates the destination buffer first and checks for enough bytes afterwards, so an absurd length becomes an absurd allocation.
The lesson is old and still current: a length that comes from a file is a claim, not a fact. Check it against the amount of data that is really there before you allocate. A file of a few dozen bytes can ask for gigabytes, and the cost to the attacker is nothing.
The damage is a crash of the process. For a service that handles many users in one Node.js process, one bad upload takes everyone down. The record does not mark this CVE as known exploited.
Try it yourself
See how this kind of finding shows up in a dependency workflow.
Click through it at your own pace, or open it full screen.
Quick check
Is every version before 11.16.0 affected?
The record says prior to 11.16.0. The advisory lists 11.12.3 as the affected version. Upgrade to be safe.
Is this exploitable remotely?
The CVSS vector says local, but the advisory impact says remote unauthenticated denial of service where untrusted MP4 files are parsed.
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.
