Blog
ExifReader Caps Compressed Image Metadata After CVE-2026-8814 DoS Advisory
ExifReader has patched CVE-2026-8814, a denial-of-service issue in asynchronous image metadata parsing that allowed crafted compressed PNG or JPEG XL metadata blocks to consume excessive heap and CPU. Version 4.39.0 adds a configurable decompressed-size cap.
Overview
ExifReader has published a security advisory for CVE-2026-8814, a denial-of-service issue in versions 4.20.0 through 4.38.1 of the JavaScript image-metadata parser. The advisory rates the issue as moderate severity and lists version 4.39.0 as the first patched release.
The issue appears when an application uses ExifReader's asynchronous API on an attacker-supplied image. A small compressed metadata block can expand to hundreds of megabytes in memory, consuming heap and CPU until the browser or other JavaScript process slows down or runs out of memory.
Affected Metadata Paths
The affected decompression utility is shared by multiple metadata paths. The advisory lists PNG zTXt, compressed iTXt, and iCCP chunks using deflate compression, along with Brotli-compressed Exif and XMP blocks in JPEG XL files.
ExifReader's advisory says a typical proof of concept produced roughly 1,000x expansion: about 32 KB of compressed input could expand to about 32 MB, while about 130 KB could expand to about 128 MB. The npm package and the repository's prebuilt dist bundle were both affected.
Patched Behavior
ExifReader 4.39.0 changes decompression so the library reads the output stream incrementally and stops before a metadata block exceeds a configured limit. The default cap is 128 MiB per block, and applications can set a lower value with the new decompress.maxDecompressedSize option.
When a block exceeds the limit, ExifReader skips that block, logs a warning, and returns the remaining tags. The project also says the cap applies to results returned by custom Brotli or deflate functions. Applications that cannot upgrade immediately should avoid the asynchronous API for untrusted files or validate inputs before parsing.
What This Does Not Mean
This advisory is specific to affected versions and code paths in ExifReader. It does not mean that every photo editor, metadata viewer, or browser-based image utility has the same flaw.
PhotoTools.org currently uses a different metadata dependency, exifr, rather than ExifReader. The advisory is relevant to the wider local-first image-tool ecosystem, but it is not a disclosure that PhotoTools.org itself is affected by CVE-2026-8814.
Why It Matters
Photo metadata is often discussed as a privacy concern because image files can carry GPS coordinates, capture times, camera details, thumbnails, and editing history. This advisory highlights a second concern: metadata is also input that software must parse safely, even when the visible photo looks ordinary.
Local browser processing remains valuable because files do not need to be uploaded to an app server. But local-first does not remove the need for defensive limits. Image tools still need to audit parsing libraries, bound decompression work, and treat files from unknown sources as untrusted input.