GHSA-rgwj-5xj2-c3m3

## Vulnerability Details **File**: `lib/compressed_protocol.js` **Line**: 43 (`zlib.inflate(body, (err, data) => { ... })` inside `handleCompressedPacket`) ### 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: ```js zlib.inflate(body, (err, data) => { ... }); ``` No options object (in particular, no `maxOutputLength`) is passed. Node'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 "length of payload before compression" 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. 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's memory — a classic decompression-bomb / "zip bomb" applied to MySQL's client-compression protocol. ### Attack Scenario 1. Application connects with `mysql2`/`mysql2/promise` using `compress: true` (a documented option for reducing bandwidth, commonly used for cloud/WAN DB connections). 2. The connection target is attacker-controlled or attacker-compromised, or an attacker MITMs a non-TLS connection. 3. Right after authentication succeeds, the malicious endpoint sends one crafted compressed packet whose deflate stream is small on the wire (hundreds of KB) but decompresses to several GB. 4. `zlib.inflate()` starts allocating memory for the full decompressed output with no ceiling. 5. The Node.js process's RS