GHSA-rgwj-5xj2-c3m3: MySQL2 Denial of Service Vulnerability

MODERATE
CVSS 5.9
CWE-409
Published
Advisory Summary

GHSA-rgwj-5xj2-c3m3 is a MODERATE (CVSS 5.9) denial of service vulnerability (CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)) affecting MySQL2 libraries in the npm ecosystem. The issue involves unbounded zlib inflate in compressed mysql protocol handler allows decompression-bomb dos. Remediation is available by upgrading affected packages to version 3.23.1.

GHSA-rgwj-5xj2-c3m3 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-rgwj-5xj2-c3m3
Severity MODERATE
CVSS v3.1 Base Score 5.9
CWE Classification CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
Affected Product MySQL2
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 5.9

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix GHSA-rgwj-5xj2-c3m3

To remediate this vulnerability, upgrade all affected MySQL2 dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

mysql2 fixed: 3.23.1
npm install mysql2@3.23.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls mysql2

How to Check if You Are Affected

To determine whether your Node.js application is affected by GHSA-rgwj-5xj2-c3m3, inspect your project dependencies using npm:

npm ls mysql2

Analyze the terminal output to locate any version of MySQL2 in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.23.1), your application is affected.

Note: The npm ls mysql2 command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-409: Improper Handling of Highly Compressed Data (Data Amplification), where the product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output. In MySQL2, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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 RSS grows uncontrolled until OOM-kill or crash — no query needs to be issued by the client; the malicious packet alone is enough. ### Impact Denial of Service of the client application (process crash / OOM) — not the database itself. No authentication bypass or data exposure. Requires `compress: true` plus a malicious/compromised server or MITM position. ### Vulnerable Code ```js function handleCompressedPacket(packet) { const connection = this; const deflatedLength = packet.readInt24(); const body = packet.readBuffer(); if (deflatedLength !== 0) { connection.inflateQueue.push((task) => { zlib.inflate(body, (err, data) => { if (err) { connection._handleNetworkError(err); return; } connection._bumpCompressedSequenceId(packet.numPackets); connection._inflatedPacketsParser.execute(data); task.done(); }); }); } else { ... } } ``` ### Recommended Fix ```js const MAX_INFLATED_PACKET_SIZE = 1 * 1024 * 1024 * 1024; // e.g. 1 GiB, ideally configurable zlib.inflate(body, { maxOutputLength: MAX_INFLATED_PACKET_SIZE }, (err, data) => { if (err) { connection._handleNetworkError(err); return; } ... }); ``` `maxOutputLength` makes `zlib.inflate` abort with `ERR_BUFFER_TOO_LARGE` as soon as the decompressed size would exceed the cap, routing into the exact same (already-existing) `err` → `connection._handleNetworkError(err)` path, so no new error-handling logic is required. ### Verification Dynamically confirmed on v3.23.0 (HEAD) using a minimal rogue "MySQL server" built on node-mysql2's own server-mode helpers (`mysql.createServer`, `Packets.Handshake`, `connection.writeOk()`). The rogue server completes a real handshake advertising `CLIENT_COMPRESS`, then writes one raw compressed frame (509,604 bytes on the wire — a zlib deflate of 500 MB of zero bytes, ratio 1028.8:1) directly to the socket. A normal `mysql.createConnection({ ..., compress: true })` victim client — which never issues any query — had its RSS grow from 74.3 MB to 1115.0 MB after receiving that single packet, before erroring out with `PROTOCOL_UNEXPECTED_PACKET` once the client tried to parse the inflated zero-filled buffer as MySQL packets. The memory allocation happens unconditionally before any content validation.

GHSA-rgwj-5xj2-c3m3 Affected MySQL2 Versions

1 component(s)
Fixed Versions:
3.23.1
Product / Package Ecosystem Affected Versions Fixed Version
mysql2
npm
< 3.23.1
3.23.1

References

Frequently Asked Questions

What is GHSA-rgwj-5xj2-c3m3?
GHSA-rgwj-5xj2-c3m3 is a security vulnerability in MySQL2 involving Unbounded zlib inflate in compressed MySQL protocol handler allows decompression-bomb DoS under CWE-409: Improper Handling of Highly Compressed Data (Data Amplification).
Which MySQL2 versions are affected?
Affected versions include releases prior to 3.23.1 across affected packages: mysql2.
What version fixes GHSA-rgwj-5xj2-c3m3?
Upgrading to 3.23.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is mysql2 affected?
Yes, mysql2 is affected in releases prior to 3.23.1. Upgrade your dependency to 3.23.1 or later.
What is the CVSS score of GHSA-rgwj-5xj2-c3m3?
GHSA-rgwj-5xj2-c3m3 has a CVSS v3.1 base score of 5.9 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with GHSA-rgwj-5xj2-c3m3?
GHSA-rgwj-5xj2-c3m3 is classified under CWE-409: Improper Handling of Highly Compressed Data (Data Amplification) (The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.).
How can I check npm dependencies for GHSA-rgwj-5xj2-c3m3?
Run the dependency tree command: 'npm ls mysql2'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-rgwj-5xj2-c3m3",
  "modified" : "2026-09-02T15:28:46Z",
  "published" : "2026-08-31T22:36:20Z",
  "aliases" : [ ],
  "summary" : "MySQL2: Unbounded zlib inflate in compressed MySQL protocol handler allows decompression-bomb DoS",
  "details" : "## Vulnerability Details\n\n**File**: `lib/compressed_protocol.js`\n**Line**: 43 (`zlib.inflate(body, (err, data) => { ... })` inside `handleCompressedPacket`)\n\n### Root Cause\nWhen 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:\n\n```js\nzlib.inflate(body, (err, data) => { ... });\n```\n\nNo 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.\n\nBecause 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.\n\n### Attack Scenario\n1. Application connects with `mysql2`/`mysql2/promise` using `compress: true` (a documented option for reducing bandwidth, commonly used for cloud/WAN DB connections).\n2. The connection target is attacker-controlled or attacker-compromised, or an attacker MITMs a non-TLS connection.\n3. 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.\n4. `zlib.inflate()` starts allocating memory for the full decompressed output with no ceiling.\n5. The Node.js process's RSS grows uncontrolled until OOM-kill or crash — no query needs to be issued by the client; the malicious packet alone is enough.\n\n### Impact\nDenial of Service of the client application (process crash / OOM) — not the database itself. No authentication bypass or data exposure. Requires `compress: true` plus a malicious/compromised server or MITM position.\n\n### Vulnerable Code\n```js\nfunction handleCompressedPacket(packet) {\n  const connection = this;\n  const deflatedLength = packet.readInt24();\n  const body = packet.readBuffer();\n\n  if (deflatedLength !== 0) {\n    connection.inflateQueue.push((task) => {\n      zlib.inflate(body, (err, data) => {\n        if (err) {\n          connection._handleNetworkError(err);\n          return;\n        }\n        connection._bumpCompressedSequenceId(packet.numPackets);\n        connection._inflatedPacketsParser.execute(data);\n        task.done();\n      });\n    });\n  } else {\n    ...\n  }\n}\n```\n\n### Recommended Fix\n```js\nconst MAX_INFLATED_PACKET_SIZE = 1 * 1024 * 1024 * 1024; // e.g. 1 GiB, ideally configurable\n\nzlib.inflate(body, { maxOutputLength: MAX_INFLATED_PACKET_SIZE }, (err, data) => {\n  if (err) {\n    connection._handleNetworkError(err);\n    return;\n  }\n  ...\n});\n```\n`maxOutputLength` makes `zlib.inflate` abort with `ERR_BUFFER_TOO_LARGE` as soon as the decompressed size would exceed the cap, routing into the exact same (already-existing) `err` → `connection._handleNetworkError(err)` path, so no new error-handling logic is required.\n\n### Verification\nDynamically confirmed on v3.23.0 (HEAD) using a minimal rogue \"MySQL server\" built on node-mysql2's own server-mode helpers (`mysql.createServer`, `Packets.Handshake`, `connection.writeOk()`). The rogue server completes a real handshake advertising `CLIENT_COMPRESS`, then writes one raw compressed frame (509,604 bytes on the wire — a zlib deflate of 500 MB of zero bytes, ratio 1028.8:1) directly to the socket. A normal `mysql.createConnection({ ..., compress: true })` victim client — which never issues any query — had its RSS grow from 74.3 MB to 1115.0 MB after receiving that single packet, before erroring out with `PROTOCOL_UNEXPECTED_PACKET` once the client tried to parse the inflated zero-filled buffer as MySQL packets. The memory allocation happens unconditionally before any content validation.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "mysql2"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.23.1"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.23.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/sidorares/node-mysql2/security/advisories/GHSA-rgwj-5xj2-c3m3"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/sidorares/node-mysql2/commit/7c48343c95ecc80d30d6ebfa67875947b7d848d2"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/sidorares/node-mysql2"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/sidorares/node-mysql2/releases/tag/v3.23.1"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-409" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-31T22:36:20Z",
    "nvd_published_at" : null
  }
}