chore: bump up file-type version to v21.3.2 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
file-type	21.0.0 → 21.3.2

GitHub Vulnerability Alerts

CVE-2026-31808

Impact

A denial of service vulnerability exists in the ASF (WMV/WMA) file type detection parser. When parsing a crafted input where an ASF sub-header has a size field of zero, the parser enters an infinite loop. The payload value becomes negative (-24), causing tokenizer.ignore(payload) to move the read position backwards, so the same sub-header is read repeatedly forever.

Any application that uses file-type to detect the type of untrusted/attacker-controlled input is affected. An attacker can stall the Node.js event loop with a 55-byte payload.

Patches

Fixed in version 21.3.1. Users should upgrade to >= 21.3.1.

Workarounds

Validate or limit the size of input buffers before passing them to file-type, or run file type detection in a worker thread with a timeout.

References

• Fix commit: 319abf871b50ba2fa221b4a7050059f1ae096f4f

Reporter

crnkovic@lokvica.com

CVE-2026-32630

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:

const maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)
	? maximumZipEntrySizeInBytes
	: Number.MAX_SAFE_INTEGER;

and:

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

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

---

Release Notes

sindresorhus/file-type (file-type)

v21.3.2

Compare Source

• Fix ZIP bomb in known-size ZIP probing (GHSA-j47w-4g3g-c36v) a155cd7
• Fix bound recursive BOM and ID3 detection 370ed91

---

v21.3.1

Compare Source

• Fix infinite loop in ASF parser on malformed input (GHSA-5v7r-6r5c-r473) 319abf8

---

v21.3.0

Compare Source

• Add support for Mach-O Universal (aka "Fat") binaries and additional architectures (#​779) d223491

---

v21.2.0

Compare Source

• Add support for SPSS data files (#​787) 889f638
• Add support for JMP (#​784) 093dba0

---

v21.1.1

Compare Source

• Fix handling of partial Gunzip file (#​783) 710e053

---

v21.1.0

Compare Source

• Add support for .tar.gz (gunzipped tarball file) (#​763) eda03a7
• Add support for Windows registry (.reg) files 0db61ec 7d2ddcf
• Add support for Windows registry hive file (.dat) (#​767) f8d62be
• Fix: Handle partial unzip (#​773) 7ad3a90

---

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
blocksuite	Ready	Preview, Comment	Mar 13, 2026 1:41pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
blocksuite-docs	Ignored	Preview	Mar 13, 2026 1:41pm