Affected: npm: mysql2

## 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 opt…