Netdata WebSocket Decompression Bomb DoS (GHSA-c8p4-cg3j-f4h2)

WebSocket Decompression Bomb Vulnerability (GHSA-c8p4-cg3j-f4h2) Vulnerability Overview Netdata's WebSocket server accepts compressed messages with a maximum decompressed size of 200MB, and lacks compression ratio validation. An unauthenticated attacker can send a 100-byte compressed payload, forcing the server to allocate approximately 200MB of memory, leading to a Denial of Service (DoS) via memory exhaustion. Root Cause: In the function, the output buffer grows to (200MB), but the ratio between compressed and decompressed sizes is not checked. Existing checks ( and ) only limit the frame size and maximum decompressed size, without restricting the compression ratio. Affected Scope Affected Versions: Fixed Versions: Severity: High (7.5/10) Attack Vector: Network Exploitation Conditions: No authentication required, no user interaction required Attack Flow 1. Attacker connects to port 19999 (no authentication required) 2. WebSocket handshake negotiates the extension 3. Compression is accepted at , prior to any authentication checks 4. Attacker sends a text frame containing approximately 100 bytes of zlib-compressed zeros 5. Server invokes , allocating up to 200MB 6. Repeating this operation across multiple connections exhausts server memory Reproduction/Output Example 25 unauthenticated WebSocket connections killed the netdata process within 2.5 seconds. The server's VmRSS increased from 67 MB to 2,928 MB, after which the OOM killer terminated the process (exit code 137) in 2 seconds. Total attack bandwidth was approximately 5 MB per bomb. Remediation Primary Fix Add compression ratio validation in the function after line 312: Additional Recommendations Reduce from 200MB to a more reasonable limit (e.g., 10MB) Consider implementing per-connection memory limits Consider rate-limiting decompression operations

Goal Reached Thanks to every supporter — we hit 100%!

Netdata WebSocket Decompression Bomb DoS (GHSA-c8p4-cg3j-f4h2)

More from this source