CVE-2026-32630

What it actually does

CVE-2026-32630 is a denial-of-service vulnerability in the Node.js file-type library affecting versions 20.0.0 through 21.3.1. When applications call fileTypeFromBuffer(), fileTypeFromBlob(), or fileTypeFromFile() on a crafted ZIP file, the library can inflate and inspect a much larger payload than expected while probing ZIP-derived formats such as OOXML documents. The ZIP inflate output limit is applied for stream-based detection paths, but not for known-size inputs, allowing a small uploaded or supplied file to cause excessive memory growth and potentially crash the Node.js process or trigger container memory limits.

Why it matters to the business

Applications that accept untrusted files and use file-type for file identification may be susceptible to service instability or outages from a small malicious file. The likely impact is availability loss rather than data theft or integrity compromise. EPSS is low and there is no known CISA KEV listing or reported ransomware use, but the library is commonly used in file-upload, content-validation, messaging, document-processing, and media-handling workflows, so vulnerable deployments can still face operational disruption if exposed to anonymous or unauthenticated file submissions.

How an attack unfolds

An attacker identifies an endpoint or workflow that accepts file uploads, attachments, blobs, or externally fetched files and where the backend uses file-type versions 20.0.0 through 21.3.1 with fileTypeFromBuffer(), fileTypeFromBlob(), or fileTypeFromFile(). The attacker submits a deliberately crafted ZIP archive that is small on the wire but expands to a much larger amount of data during ZIP probing. As file-type attempts to determine whether the ZIP represents an OOXML or other ZIP-based format, memory usage grows excessively because the inflate limit is not enforced for these known-size input paths. Repeated requests can crash worker processes, exhaust container memory, trigger automatic restarts, degrade queue processing, or make upload/document-processing functionality unavailable.

How to fix it

Upgrade sindresorhus file-type to version 21.3.2 or later wherever it is used. Regenerate lockfiles and redeploy all affected services, workers, serverless functions, and container images that bundle the dependency. If immediate upgrade is not possible, prefer stream-based detection paths where practical, enforce strict upload size limits, reject or quarantine compressed archives from untrusted sources, apply per-request memory and time limits, and isolate file inspection in a constrained worker process. Add rate limiting and authentication to upload or ingestion endpoints where possible, and ensure process supervisors restart failed workers without causing cascading outages.

How to confirm the fix worked

Confirm no deployed package resolves file-type to versions 20.0.0 through 21.3.1 by checking package lockfiles, SBOMs, container images, and runtime dependency trees. For npm-based projects, run dependency inventory commands such as npm ls file-type, pnpm why file-type, or yarn why file-type and verify the resolved version is 21.3.2 or later. Exercise upload and file-processing workflows with benign ZIP, DOCX, XLSX, and PPTX files after upgrading to ensure compatibility. Where safe and authorized, test resource controls with oversized compressed test archives in a non-production environment and verify that memory consumption remains bounded and the service rejects or safely handles the input.

Typical attack path

1. Find an application endpoint or automated ingestion path that accepts user-controlled files, attachments, or URLs that resolve to files.
2. Infer or confirm that the service performs server-side file type detection using the vulnerable file-type library version range.
3. Create a compressed ZIP payload with a small submitted size but a very large inflated content size, especially one that triggers ZIP-based format probing such as OOXML detection.
4. Submit the crafted file through the upload, API, messaging, or ingestion workflow.
5. Cause the Node.js process to allocate excessive memory during file type detection.
6. Repeat submissions as needed to crash processes, exhaust container memory, increase restart loops, or degrade availability.

How to detect it

Look for evidence of denial-of-service attempts around file upload, attachment processing, document conversion, antivirus pre-processing, media ingestion, and URL-to-file import workflows. Relevant log sources include application logs, API gateway and reverse proxy access logs, file-processing worker logs, container orchestrator events, process supervisor logs, Node.js runtime stderr, APM memory metrics, and object-storage access logs if uploads are staged before processing. Investigate spikes in memory usage, worker restarts, HTTP 500/502/503 responses after upload requests, Kubernetes OOMKilled events, container exit code 137, Node.js heap exhaustion messages, and repeated submissions of small ZIP-like files followed by service crashes. Correlate suspicious requests by source IP, account, user agent, upload filename, content type, request size, and timing. There are no public, unique exploit payload signatures provided for this vulnerability, so detection should focus on behavioral indicators: compressed files that are small at rest but trigger unusually high memory consumption during file-type detection, especially when application stack traces mention fileTypeFromBuffer(), fileTypeFromBlob(), fileTypeFromFile(), ZIP probing, or OOXML detection.

• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• OOMKilled
• exit code 137
• Killed process node
• fileTypeFromBuffer
• fileTypeFromBlob
• fileTypeFromFile
• node_modules/file-type
• "file-type": "20.
• "file-type": "21.0.
• "file-type": "21.1.
• "file-type": "21.2.
• "file-type": "21.3.0"
• "file-type": "21.3.1"

What your security team should do

• Prioritize inventory of externally reachable upload, attachment, document-processing, and file-ingestion services that use the Node.js file-type package.
• Upgrade all uses of file-type versions 20.0.0 through 21.3.1 to 21.3.2 or later, including transitive dependency resolutions where the package is bundled into applications.
• Review dependency lockfiles and container images to ensure stale vulnerable versions are not still deployed after source-level updates.
• Add or verify upload controls: maximum compressed file size, maximum decompressed size, request timeout, memory limit, and rate limiting for unauthenticated or public endpoints.
• Monitor application and container logs for Node.js out-of-memory errors, abrupt process exits, restart loops, and spikes in memory use correlated with file upload or ingestion events.
• Consider moving risky file inspection into isolated worker pools with strict resource quotas so a parser failure cannot take down primary application processes.
• Because current EPSS is low, no KEV listing exists, and exploit maturity is reported as none, treat this as important for exposed file-processing services but generally below actively exploited remote-code-execution or credential-theft vulnerabilities.