4vulnerabilities
- Critical0 (0.0%)
- High2 (50.0%)
- Medium0 (0.0%)
- Moderate2 (50.0%)
- Low0 (0.0%)
exifreader
Ecosystem: npm
Downloads:
- 0CriticalAffects 0 versions
- 2HighAffects 2 versions
- 0MediumAffects 0 versions
- 2ModerateAffects 2 versions
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 1
- Low: 0
- 2 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 1
- Low: 0
Vulnerabilities (4)
Known vulnerabilities affecting exifreader, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-pj96-35fp-cfcc | High | ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion## Summary 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: |
| GitHub (opens in a new tab) | |
| GHSA-g77h-45rf-hcx4 | Moderate | ExifReader HEIC/AVIF ISO-BMFF parser throws uncaught RangeError on truncated boxes## Summary 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 |
| GitHub (opens in a new tab) | |
| GHSA-h64w-w9pr-82m4 | High | ExifReader is vulnerable to denial of service via crafted ICC `mluc` tag### 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 |
| GitHub (opens in a new tab) | |
| GHSA-rr89-w3h9-m66j | Moderate | ExifReader is vulnerable to denial of service via unbounded decompression of image metadata### 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 |
| GitHub (opens in a new tab) |
- GHSA-pj96-35fp-cfccHighExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion
< 4.41.1
## Summary 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:
CVE: CVE-2026-85715
- GHSA-g77h-45rf-hcx4ModerateExifReader HEIC/AVIF ISO-BMFF parser throws uncaught RangeError on truncated boxes
< 4.40.1
## Summary 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
CVE: CVE-2026-53496
- GHSA-h64w-w9pr-82m4HighExifReader is vulnerable to denial of service via crafted ICC `mluc` tag
>= 2.10.0, < 4.39.0
### 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
CVE: CVE-2026-8813
- GHSA-rr89-w3h9-m66jModerateExifReader is vulnerable to denial of service via unbounded decompression of image metadata
>= 4.20.0, < 4.39.0
### 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
CVE: CVE-2026-8814