EUVD-2026-30842
GHSA-rr89-w3h9-m66j
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
4Blast Radius
ecosystem impact- 10 npm packages depend on exifreader (10 direct, 0 indirect)
Ecosystem-wide dependent count for version 4.20.0.
DescriptionCVE.org
Versions of the package exifreader before 4.39.0 are vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) due to decompressing PNG zTXt metadata without enforcing a built-in maximum decompressed output size. When asynchronous parsing is enabled, a crafted PNG file containing a highly compressed zTXt chunk can cause ExifReader to materialize a disproportionately large Comment value in memory.
AnalysisAI
Decompression bomb (data amplification) in ExifReader npm package before 4.39.0 allows remote unauthenticated attackers to exhaust server memory by supplying a crafted PNG file with a highly compressed zTXt metadata chunk. The vulnerable path activates only when the caller enables asynchronous parsing (async: true), at which point ExifReader decompresses the chunk via the Compression Streams API with no upper bound on output size. Publicly available proof-of-concept exploit code exists (E:P); this CVE is not listed in CISA KEV.
Technical ContextAI
ExifReader (cpe:2.3:a:n/a:exifreader:*:*:*:*:*:*:*:*) is a JavaScript library that parses image metadata across formats including JPEG, PNG, HEIC, and WebP. PNG files support zTXt chunks, which store arbitrary textual metadata compressed with zlib DEFLATE. CWE-409 (Improper Handling of Highly Compressed Data) describes the root cause class: libraries that decompress attacker-controlled data without enforcing an output-size limit can be forced to materialize disproportionately large buffers - a decompression bomb. The vulnerable code path in ExifReader uses the browser/Node Compression Streams API (or caller-supplied custom decompression functions) to expand zTXt content asynchronously, and prior to 4.39.0, no maximum decompressed size was enforced. The fix commit (5f116128) introduces a decompress.maxDecompressedSize option defaulting to 128 MiB; blocks exceeding the limit are skipped with a console.warn and remaining tags are returned normally.
RemediationAI
Upgrade ExifReader to version 4.39.0 or later; this is the vendor-released patch confirmed by upstream commit 5f116128adc19f674902f8bf582bfe7dd0a36375 (https://github.com/mattiasw/ExifReader/commit/5f116128adc19f674902f8bf582bfe7dd0a36375) and the corresponding CHANGELOG entry. After upgrading, applications with stricter memory budgets should lower the default 128 MiB cap by passing decompress: { maxDecompressedSize: 16 * 1024 * 1024 } alongside async: true; blocks exceeding the limit are silently skipped with a warning, so this may omit legitimate but unusually large metadata. If an immediate upgrade is not possible, the most direct compensating control is to remove async: true from all ExifReader.load() calls - this eliminates the vulnerable decompression path entirely at the cost of losing async performance benefits. A secondary compensating control is to validate and reject PNG files above a conservative raw file-size threshold before passing them to ExifReader; note this limits input size but does not directly bound decompressed output, so it provides weaker guarantees than the patch. See the Snyk advisory at https://security.snyk.io/vuln/SNYK-JS-EXIFREADER-16689340 for additional guidance.
More in Exifreader
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today