https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 23 Oct 2026 14:27:22 +0000 https://db.gcve.eu/vuln/ghsa-rcw4-f5rp-g42v <p><strong>Affected:</strong> npm: adm-zip</p> <p>**Affected package:** adm-zip (npm) **Affected version:** 0.6.0</p> <p>## Summary</p> <p>The fix shipped for CVE-2026-39244 (`methods/inflater.js`) caps zlib&#39;s decompression output via `maxOutputLength: expectedLength`, where `expectedLength` is read directly from the ZIP entry&#39;s attacker-controlled &#34;uncompressed size&#34; header field (`CENLEN`/`LOCLEN`). This cap is only applied when `expectedLength &gt; 0`:</p> <p>```js const option = version &gt;= 15 &amp;&amp; expectedLength &gt; 0 ? { maxOutputLength: expectedLength } : {}; return zlib.inflateRawSync(inbuf, option); ```</p> <p>If an attacker sets the declared uncompressed-size field to exactly **0**, this condition is false, `option` becomes `{}`, and no output cap is passed to zlib at all. Node then falls back to zlib&#39;s own internal default limit (several GB), so a small, highly-compressible payload can still be decompressed to a very large size in memory -- the same class of resource-exhaustion issue the original CVE addressed, just triggered differently.</p> <p>## Steps to Reproduce</p> <p>1. Build a ZIP archive containing one DEFLATE-compressed entry whose real content is highly redundant (e.g. several MB of a repeated byte, achieving close to the ~1032:1 theoretical raw-DEFLATE compression ratio). 2. Patch the entry&#39;s declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to `0`. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real d…</p> <p><strong>Affected:</strong> npm: adm-zip</p> <p>**Affected package:** adm-zip (npm) **Affected version:** 0.6.0</p> <p>## Summary</p> <p>The fix shipped for CVE-2026-39244 (`methods/inflater.js`) caps zlib&#39;s decompression output via `maxOutputLength: expectedLength`, where `expectedLength` is read directly from the ZIP entry&#39;s attacker-controlled &#34;uncompressed size&#34; header field (`CENLEN`/`LOCLEN`). This cap is only applied when `expectedLength &gt; 0`:</p> <p>```js const option = version &gt;= 15 &amp;&amp; expectedLength &gt; 0 ? { maxOutputLength: expectedLength } : {}; return zlib.inflateRawSync(inbuf, option); ```</p> <p>If an attacker sets the declared uncompressed-size field to exactly **0**, this condition is false, `option` becomes `{}`, and no output cap is passed to zlib at all. Node then falls back to zlib&#39;s own internal default limit (several GB), so a small, highly-compressible payload can still be decompressed to a very large size in memory -- the same class of resource-exhaustion issue the original CVE addressed, just triggered differently.</p> <p>## Steps to Reproduce</p> <p>1. Build a ZIP archive containing one DEFLATE-compressed entry whose real content is highly redundant (e.g. several MB of a repeated byte, achieving close to the ~1032:1 theoretical raw-DEFLATE compression ratio). 2. Patch the entry&#39;s declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to `0`. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real d…</p> https://db.gcve.eu/vuln/ghsa-rcw4-f5rp-g42v