https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 16:20:41 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-319413 EUVD-2026-319413 https://cve.radiocsirt.org/vuln/euvd-2026-319413 https://cve.radiocsirt.org/vuln/fkie_cve-2026-8814 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-8814 https://cve.radiocsirt.org/vuln/ghsa-rr89-w3h9-m66j <p><strong>Affected:</strong> npm: exifreader</p> <p>### Impact</p> <p>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.</p> <p>The affected paths share a single decompression utility, so the issue is reachable through any compressed metadata block the library handles asynchronously, including:</p> <p>- PNG `zTXt`, compressed `iTXt`, and `iCCP` chunks (deflate) - JPEG XL Brotli-compressed Exif and XMP blocks</p> <p>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).</p> <p>Both the npm package and the `dist/` bundle published from this repository (consumed by Bower and other users of the prebuilt artifact) are affected.</p> <p>### Patches</p> <p>Fixed in **4.39.0**. The decompression utility now reads the decompressed stream incrementally and aborts as soon as the running total would exceed a configurable limit. The default cap is **128 MiB** per metadata block, which is well above any realistic legitimate value. When a block exceeds the cap, that block is skipped (a warning is emitted via `console.warn`) and the remaining tags are returned as usual.</p> <p>The cap is configurable via the new `maxDecompressedSize` field…</p> <p><strong>Affected:</strong> npm: exifreader</p> <p>### Impact</p> <p>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.</p> <p>The affected paths share a single decompression utility, so the issue is reachable through any compressed metadata block the library handles asynchronously, including:</p> <p>- PNG `zTXt`, compressed `iTXt`, and `iCCP` chunks (deflate) - JPEG XL Brotli-compressed Exif and XMP blocks</p> <p>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).</p> <p>Both the npm package and the `dist/` bundle published from this repository (consumed by Bower and other users of the prebuilt artifact) are affected.</p> <p>### Patches</p> <p>Fixed in **4.39.0**. The decompression utility now reads the decompressed stream incrementally and aborts as soon as the running total would exceed a configurable limit. The default cap is **128 MiB** per metadata block, which is well above any realistic legitimate value. When a block exceeds the cap, that block is skipped (a warning is emitted via `console.warn`) and the remaining tags are returned as usual.</p> <p>The cap is configurable via the new `maxDecompressedSize` field…</p> https://cve.radiocsirt.org/vuln/ghsa-rr89-w3h9-m66j