CVE Vulnerability Catalog

In the public development revision introduced after 11.14.0 of music-metadata, 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.

In music-metadata prior to 11.16.0, the MP4 parser accepts an attacker-controlled 64-bit extended atom size, converts it to a JavaScript Number, and uses the resulting payload length for atom-specific readToken calls before proving that the atom fits within its parent or the available input. A tiny MP4-family file can route an oversized length into payload parsing for atoms including mvhd, stsd, stsz, and date, causing a large allocation attempt or process failure before end-of-input validation. Applications that parse untrusted MP4-family media can therefore be denied service.

In music-metadata 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.

The BSON encoder in the MongoDB PHP Driver does not check some return values after a document exceeds libbson's size limit. This can leave the encoder in an invalid state. An unauthenticated actor who can cause an affected application to encode an unusually large data structure can terminate the PHP worker or cause the resulting document to omit fields. No MongoDB server connection or database authentication is required.

IBM Guardium Data Protection 12.0, 12.1, 12.2 is affected by an improper validation of user-supplied pointers in the WfpMonitor kernel driver. Certain METHOD_NEITHER IOCTL handlers dereference user-controlled pointers without adequate probing and exception handling, potentially allowing a privileged local attacker to cause a system crash or perform limited kernel-memory reads.

In music-metadata prior to 11.16.0, the ID3v2 parser trusts the syncsafe tag-size field and allocates the complete tag body before checking whether the input contains the declared bytes. A truncated file containing only an ID3v2 header can request an allocation approaching 268 MiB; the allocation succeeds, the subsequent read reaches end of stream, the EndOfStreamError is caught internally, and the caller receives a normal metadata object.

Prior to version 11.16.0, the APEv2 parser in the music-metadata library reads an attacker-controlled tag-item size and allocates a Uint8Array for a binary item before verifying that the declared size fits in the remaining data. A small crafted APE file can trigger a disproportionate allocation, and repeated or concurrent parsing can exhaust process memory. This issue is fixed in version 11.16.0.

In the amqp091-go library (Go AMQP 0.9.1 client) from version 1.13.0 to 1.14.0, the frame-size mitigation can be bypassed before connection.tune completes because Connection.maxFrameSize uses zero for both the not-yet-negotiated and negotiated-unlimited states. A malicious or compromised AMQP peer can send a short body-frame header with a large declared payload length, causing memory allocation before the payload is received or the frame's protocol state is rejected. This issue is fixed in version 1.14.0.

In MariaDB Connector/Node.js from version 3.3.0 to 3.5.4, the zero-configuration TLS fingerprint-validation path calls Ed25519PasswordAuth.hash() through Authentication.validateFingerPrint, but Ed25519PasswordAuth.hash() references a seed identifier that is not in scope. Under specific conditions (TCP connection, TLS enabled with ssl: true or an ssl object with rejectUnauthorized not false, a password set, no ssl.ca configured, and client_ed25519 negotiated), a synchronous ReferenceError can escape the socket data handler, causing the client process to terminate under Node.js default uncaught-exception behavior. This issue is fixed in version 3.5.4.

Improper validation of a BSON array length in the MongoDB Go Driver can cause an out-of-bounds index and runtime panic when an application calls bson.RawArray.Validate or bsoncore.Array.Validate on a malformed four-byte array. An unauthenticated actor who can supply raw BSON array data to an affected application may terminate an unprotected application process, causing a denial of service.

An integer overflow in BSON value-length handling in the MongoDB Go Driver can cause a runtime panic when an application validates or accesses a malformed BSON document. An unauthenticated actor who can supply BSON bytes to an affected application may terminate an unprotected application process, causing a denial of service.

An incorrect calculation in Decimal128 string parsing in the MongoDB C Driver can accept certain over-precision inputs containing leading zeros instead of rejecting them. This produces a value different from the supplied text. An actor who can provide a decimal string to an embedding application, including through Extended JSON parsing, can cause the application to store or use an incorrect numeric value.

The BSON buffer-reservation API in the MongoDB C Driver can record a length smaller than the five-byte BSON minimum. Later append or comparison operations can underflow unsigned length calculations and read or write outside the document buffer. An actor who can influence the length supplied by an embedding application can cause the application to terminate or read or corrupt adjacent process memory.

The explicit decryption component of MongoDB libmongocrypt can return an unrecognized encrypted payload unchanged instead of returning a decryption error. An actor who can modify stored encrypted fields, such as a database writer, server, or network intermediary, can cause an affected application to process the supplied bytes as decrypted plaintext.

An off-by-one error in the BSON bulk document writer in the MongoDB C Driver can write one zero byte immediately past a heap allocation when a document ends at a specific buffer boundary. An actor who can influence the size of documents serialized by an embedding application can corrupt adjacent process memory or terminate the process.

The MongoDB C++ Driver discards content after an embedded NUL byte in certain field and collection names accepted by the collection API. This can cause the driver and the calling application to interpret the same name differently. An authenticated actor who can influence a name passed by an affected application can cause the application to read distinct values from an unintended field or rename an unintended collection.

An integer underflow in MongoDB libmongocrypt's KMS endpoint-parsing logic can cause an allocation failure that terminates the application process. This can occur when an authenticated user modifies a key document in the key vault collection, or when an application accepts a KMS endpoint containing a colon after its path or query during key creation. The issue does not access memory outside its allocated bounds.

Docker Sandboxes compared OAuth token-endpoint hostnames case-sensitively when deciding whether to mask managed credential responses, while request routing treated DNS hostnames case-insensitively. Untrusted code inside a sandbox could use a case-variant hostname to reach the genuine provider endpoint while bypassing response masking. If a user completed the OAuth flow, the provider's access and refresh tokens could be returned unmasked to the sandbox, exposing host-managed credentials.

Docker Sandboxes could forward a client-supplied credential alongside a credential injected by the host egress proxy. The proxy removed alternate credentials only when their values matched known sentinel values, so untrusted code in an authorized sandbox could supply an unrecognized credential in another supported authentication header. For affected upstream services, this could authenticate the request to an attacker-controlled account and expose data included in the request.

Docker Sandboxes could fail open while masking credentials in protected proxy responses. When a response-body read returned data together with an error, affected handlers could forward unmasked bytes. Code inside an authorized sandbox could use this to recover host-managed OAuth access and refresh tokens or a derived Anthropic API key intended to remain outside the sandbox.