Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ExifReader 4.41.0 is vulnerable to denial of service through a crafted HEIC or AVIF file with a malicious iloc box. When offsetSize, lengthSize, and baseOffsetSize are set to zero in the iloc header, the extent-parsing loop allocates an unbounded number of JavaScript objects - up to itemCount × extentCount (65535 × 65535 = 4.3 billion) - without advancing the buffer offset. A 652-byte file causes 400MB of heap growth; a 6KB file exhausts all system memory and crashes the Node.js process with a JavaScript heap out-of-memory error. Affected version tested - npm package: exifreader - Version: 4.41.0 - Affected formats: HEIC, AVIF (ISO-BMFF container) Root cause File: src/image-header-iso-bmff-iloc.js, lines 79–116, function getItems(). The iloc parser reads four size fields from the file (each a 4-bit nibble, valid values 0–15): | Field | Controls | |-------|----------| | offsetSize | Bytes per extent offset | | lengthSize | Bytes per extent length | | baseOffsetSize | Bytes per…
Recommended action: Upgrade to 4.41.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ExifReader 4.40.0 can throw an uncaught RangeError: Offset is outside the bounds of the DataView while parsing crafted HEIC/AVIF files. The file only needs a valid leading ftyp box with a HEIC/AVIF major brand followed by a malformed ISO-BMFF box, such as an empty 8-byte free box or a truncated extended-size box. This is reachable through the public ExifReader.load() API for in-memory buffers and through the async file/URL loaders when an application parses attacker-supplied images. In applications that do not wrap every parse in a defensive try/catch, a single uploaded or fetched image can abort the request/worker and cause a denial of service. Credit requested: Yaohui Wang. Affected version tested - npm package: exifreader - Version: 4.40.0 - Repository commit tested: 8cb0261a26b7d986955fe0a6780f076dcb7902e7 Root cause The ISO-BMFF parser assumes that every top-level box with at least an 8-byte header also has enough bytes for the fields required by its parsed form. In…
Recommended action: Upgrade to 4.40.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When parsing an image with an embedded ICC profile that contains a crafted multiLocalizedUnicodeType (mluc) tag, ExifReader can be made to allocate memory proportional to attacker-controlled fields in the tag rather than to the actual size of the input. Processing such an image causes excessive memory consumption and can terminate the host process (out-of-memory). Any application that calls ExifReader.load() on untrusted images, for example, user uploads in a web service, is affected. ICC profiles are carried in JPEG, TIFF, PNG, HEIC, AVIF, JPEG XL, and WebP, so the issue is reachable from any of those formats. Patches Fixed in exifreader@4.39.0. Upgrade with: npm install exifreader@latest Bower users consume the bundled dist/ files from this repository, and the same fix is committed there. Workarounds If upgrading is not immediately possible, configure a custom build that excludes the icc module so that ICC parsing (and therefore this code path) is skipped entirely. Resources…
Recommended action: Upgrade to 4.39.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Versions of ExifReader from 4.20.0 through 4.38.1 do not bound the size of decompressed metadata blocks. When a caller invokes the asynchronous API (e.g. ExifReader.load(file) or ExifReader.load(buffer, {async: true})) on an attacker-supplied image, a small compressed chunk in the file can expand to hundreds of megabytes of memory, consuming heap and CPU until the process slows down or runs out of memory. The affected paths share a single decompression utility, so the issue is reachable through any compressed metadata block the library handles asynchronously, including: - PNG zTXt, compressed iTXt, and iCCP chunks (deflate) - JPEG XL Brotli-compressed Exif and XMP blocks A typical proof of concept produced roughly 1000× expansion (for example, ~32 KB of compressed input expanded to ~32 MB of output, ~130 KB to ~128 MB). Both the npm package and the dist/ bundle published from this repository (consumed by Bower and other users of the prebuilt artifact) are affected. Patches…
Recommended action: Upgrade to 4.39.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.