CVE-2026-32630: Denial of Service via Data Amplification in file-type npm Package

The file-type package is a widely adopted Node.js library responsible for determining the underlying file type of a given buffer, stream, or file path. It relies on inspecting binary

The file-type package is a widely adopted Node.js library responsible for determining the underlying file type of a given buffer, stream, or file path. It relies on inspecting binary magic numbers and parsing container format headers. To accurately identify Office Open XML (OOXML) documents, such as .docx or .xlsx, the library must parse the underlying ZIP container structure and extract specific internal entries for inspection.

The vulnerability, identified as CWE-409 (Improper Handling of Highly Compressed Data), resides in the ZIP handling logic used during this identification phase. When processing ZIP-based file formats, the library allocates memory to decompress internal metadata entries, specifically [Content_Types].xml. A design flaw in the limit enforcement mechanism allows an attacker to supply a small file that expands to a massive size during decompression.

This flaw manifests as an asymmetric resource consumption issue. The library requires minimal CPU and memory to read the compressed payload, but the extraction routine attempts to allocate memory proportional to the uncompressed size of the internal file. An unauthenticated attacker can supply a specially crafted ZIP file to any endpoint utilizing the vulnerable functions, resulting in a severe Denial of Service condition.

The root cause of CVE-2026-32630 is an erroneous conditional check within the ZipHandler component that dictates maximum decompression sizes. The library is intended to cap the decompressed size of any analyzed ZIP entry at 1 MiB (maximumZipEntrySizeInBytes) to prevent excessive memory consumption. However, this limit is selectively applied based on the input stream's characteristics.

Specifically, the library evaluates whether the file size of the input is known prior to extraction. When parsing data from a pre-allocated Buffer or a localized file (where the total byte length is pre-determined), the library bypasses the 1 MiB restriction. In these instances, the maximum decompression length is set to Number.MAX_SAFE_INTEGER, which equates to 9,007,199,254,740,991 bytes.

Because the input size is known, the library mistakenly assumes that the uncompressed data will also be manageable or bounded by the input size. This logic fails to account for the fundamental nature of DEFLATE compression, where a highly repetitive input string of minimal size can decompress into a contiguous buffer of immense proportions. Consequently, the decompressDeflateRawWithLimit function attempts to allocate a V8 heap buffer matching the uncompressed size specified by the malicious payload.

The vulnerability is isolated to the inflate method within the ZipHandler.prototype in core.js. The vulnerable code executes a conditional check using hasUnknownFileSize(this.tokenizer). If the file size is known, the ternary operator assigns Number.MAX_SAFE_INTEGER to the maximumLength variable, entirely nullifying the memory safeguard.

// Vulnerable core.js (prior to 21.3.2)
ZipHandler.prototype.inflate = async function (zipHeader, fileData, callback) {
    // ...
    const maximumLength = hasUnknownFileSize(this.tokenizer) 
        ? maximumZipEntrySizeInBytes 
        : Number.MAX_SAFE_INTEGER;
    const uncompressedData = await decompressDeflateRawWithLimit(fileData, {maximumLength});
    return callback(uncompressedData);
};

The fix, introduced in commit a155cd71323279de173c54e8c530d300d3854fdd, removes this conditional logic entirely. The patch hardcodes maximumLength to the predefined maximumZipEntrySizeInBytes constant, ensuring a strict 1 MiB limit is applied regardless of the input data source.

// Patched core.js (version 21.3.2)
ZipHandler.prototype.inflate = async function (zipHeader, fileData, callback) {
    // ...
    const uncompressedData = await decompressDeflateRawWithLimit(fileData, {maximumLength: maximumZipEntrySizeInBytes});
    return callback(uncompressedData);
};

This simple code alteration guarantees that the V8 engine will reject any attempt by the decompressDeflateRawWithLimit function to allocate a buffer exceeding 1 MiB for a single ZIP entry. If the decompressed payload reaches this threshold, the decompression stream halts, preventing the Out-of-Memory condition while still reading enough metadata to determine the file type.

Exploitation of CVE-2026-32630 does not require advanced technical capabilities or specific network positioning. An attacker must construct a standard ZIP archive containing a single file named [Content_Types].xml. This file name is explicitly targeted by the library's OOXML detection routines, guaranteeing that the parsing logic will attempt decompression.

The attacker populates this XML file with highly repetitive characters, such as millions of consecutive space characters or identical XML nodes. Using standard DEFLATE compression, a multi-gigabyte text file is compressed down to a few kilobytes. This high compression ratio (often exceeding 1000:1) bypasses typical perimeter file size restrictions.

The payload is subsequently transmitted to the target application via any vector that triggers file type detection, such as an avatar upload endpoint or an attachment scanning service. When the application invokes fileTypeFromBuffer() or fileTypeFromFile(), the library initiates decompression. The Node.js process rapidly consumes available Resident Set Size (RSS) memory until it exceeds the V8 heap limit, resulting in a fatal process termination and a localized Denial of Service.

The primary impact of this vulnerability is a Denial of Service (DoS) affecting the availability of the target application. Node.js operates on a single-threaded event loop architecture. When a synchronous or resource-intensive asynchronous operation exhausts available memory, the entire V8 process crashes, terminating all active connections and halting service for all users.

The CVSS v3.1 base score is 5.3 (Medium), represented by the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. The Attack Vector is Network (AV:N), as the malicious file can be submitted remotely. The Attack Complexity is Low (AC:L) because generating a DEFLATE bomb requires standard archiving utilities. No privileges (PR:N) or user interaction (UI:N) are required.

The Availability impact is classified as Low (A:L) under CVSS v3.1 guidelines, as the system typically recovers automatically if process managers like PM2 or Docker are configured to restart crashed instances. However, repeated submission of the malicious payload will result in continuous crashes, effectively leading to sustained downtime. Confidentiality and Integrity are unaffected, as the vulnerability does not expose sensitive memory or permit arbitrary file modification.

The primary remediation strategy is an immediate upgrade to file-type version 21.3.2. This release includes the direct fix for the decompression limit bypass. Organizations should audit package-lock.json and yarn.lock files to ensure transitive dependencies are not introducing vulnerable versions of the library into the dependency tree.

In addition to the primary fix, the maintainers introduced several defense-in-depth hardening measures in version 21.3.2. Commit 69548179cca2c0ab6a0cc93af59392f8c351cab1 restricts the total number of ZIP entries processed to 1024, mitigating "death by a thousand cuts" scenarios. Commit 370ed9185d112eea4d989fecb843597b1d94cf09 caps detection recursion at 256 depths to prevent stack overflows.

For systems where immediate dependency updates are not feasible, developers should isolate file type detection logic. Executing fileTypeFromBuffer() within a Node.js Worker Thread ensures that memory exhaustion localized to the worker does not crash the primary process. Furthermore, administrators should strictly enforce maximum file upload sizes at the edge network layer (e.g., via WAF or API Gateway) prior to passing payloads to the application runtime.