https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 20:07:34 +0000 https://vulnerability.circl.lu/vuln/ghsa-rgwj-5xj2-c3m3 <p><strong>Affected:</strong> npm: mysql2</p> <p>## Vulnerability Details</p> <p>**File**: `lib/compressed_protocol.js` **Line**: 43 (`zlib.inflate(body, (err, data) =&gt; { ... })` inside `handleCompressedPacket`)</p> <p>### Root Cause When a connection is created with `compress: true` (and the server advertises `CLIENT_COMPRESS`), every incoming packet is unwrapped by `handleCompressedPacket()` in `lib/compressed_protocol.js`, which calls:</p> <p>```js zlib.inflate(body, (err, data) =&gt; { ... }); ```</p> <p>No options object (in particular, no `maxOutputLength`) is passed. Node&#39;s zlib convenience methods default `maxOutputLength` to `buffer.kMaxLength`, which on this platform is `Number.MAX_SAFE_INTEGER` — i.e. effectively unbounded until the process runs out of memory. The 3-byte &#34;length of payload before compression&#34; field in the compressed-packet header is read (`packet.readInt24()`) but is only used to branch on `!== 0`; it is never used to cap or validate the actual inflate output size, and the real decompressed size is determined purely by the attacker-supplied deflate stream.</p> <p>Because DEFLATE can reach compression ratios over 1000:1 for crafted repetitive input, an attacker who controls (or MITMs, on a non-TLS connection) the MySQL server endpoint can send a single small compressed packet that expands to gigabytes in the client&#39;s memory — a classic decompression-bomb / &#34;zip bomb&#34; applied to MySQL&#39;s client-compression protocol.</p> <p>### Attack Scenario 1. Application connects with `mysql2`/`mysql2/promise` using `compress: true` (a documented opt…</p> <p><strong>Affected:</strong> npm: mysql2</p> <p>## Vulnerability Details</p> <p>**File**: `lib/compressed_protocol.js` **Line**: 43 (`zlib.inflate(body, (err, data) =&gt; { ... })` inside `handleCompressedPacket`)</p> <p>### Root Cause When a connection is created with `compress: true` (and the server advertises `CLIENT_COMPRESS`), every incoming packet is unwrapped by `handleCompressedPacket()` in `lib/compressed_protocol.js`, which calls:</p> <p>```js zlib.inflate(body, (err, data) =&gt; { ... }); ```</p> <p>No options object (in particular, no `maxOutputLength`) is passed. Node&#39;s zlib convenience methods default `maxOutputLength` to `buffer.kMaxLength`, which on this platform is `Number.MAX_SAFE_INTEGER` — i.e. effectively unbounded until the process runs out of memory. The 3-byte &#34;length of payload before compression&#34; field in the compressed-packet header is read (`packet.readInt24()`) but is only used to branch on `!== 0`; it is never used to cap or validate the actual inflate output size, and the real decompressed size is determined purely by the attacker-supplied deflate stream.</p> <p>Because DEFLATE can reach compression ratios over 1000:1 for crafted repetitive input, an attacker who controls (or MITMs, on a non-TLS connection) the MySQL server endpoint can send a single small compressed packet that expands to gigabytes in the client&#39;s memory — a classic decompression-bomb / &#34;zip bomb&#34; applied to MySQL&#39;s client-compression protocol.</p> <p>### Attack Scenario 1. Application connects with `mysql2`/`mysql2/promise` using `compress: true` (a documented opt…</p> https://vulnerability.circl.lu/vuln/ghsa-rgwj-5xj2-c3m3