CVE-2026-83599: Netdata WebSocket DOS Vulnerability

CVE-2026-83599 Overview

Netdata, an open source observability platform, contains a decompression-bomb vulnerability in its WebSocket server. Prior to version 2.11.0, the server negotiates the permessage-deflate extension before authentication and fails to enforce a compressed-to-decompressed size ratio. The function websocket_client_decompress_message() in src/web/websocket/websocket-compression.c allows decompressed output to grow toward WS_MAX_DECOMPRESSED_SIZE (200MB). Small, highly compressed frames trigger large server-side allocations. Repeated concurrent connections exhaust memory and terminate the monitoring service. The issue is tracked as [CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)] and is fixed in Netdata 2.11.0.

Critical Impact
Unauthenticated remote attackers can exhaust Netdata server memory and terminate monitoring using small compressed WebSocket frames.

Affected Products

Netdata (open source observability agent) versions prior to 2.11.0
Deployments exposing the Netdata WebSocket endpoint to untrusted networks
Netdata Cloud connected agents running vulnerable local versions

Discovery Timeline

2026-09-22 - CVE-2026-83599 published to NVD
2026-09-23 - Last updated in NVD database
Netdata v2.11.0 - Vendor releases fixed release with decompression-bomb guard (Netdata Release v2.11.0)

Technical Details for CVE-2026-83599

Vulnerability Analysis

Netdata's WebSocket server accepts the permessage-deflate extension during the WebSocket handshake without requiring authentication. Once negotiated, any inbound frame is decompressed by websocket_client_decompress_message() in src/web/websocket/websocket-compression.c. The decompression loop grows output buffers up to WS_MAX_DECOMPRESSED_SIZE, defined as 200MB.

The pre-patch code enforced only the absolute output cap. It did not compare the compressed input size against the decompressed output size. An attacker can craft a small deflate payload that expands by a very high ratio, forcing the server to allocate up to 200MB per frame. Concurrent connections multiply the allocation and exhaust process memory, terminating monitoring on the target host.

Root Cause

The root cause is a missing ratio check on decompressed WebSocket messages, classified as [CWE-409]. Compression extensions negotiated before authentication further expand the attack surface, since no credentials are required to reach the vulnerable code path.

Attack Vector

The attack is network-reachable and requires no authentication or user interaction. An attacker opens WebSocket connections to a Netdata instance, negotiates permessage-deflate, and transmits crafted highly compressed frames. Parallel connections amplify memory pressure until the operating system kills the Netdata process.

// Patch: src/web/websocket/websocket-internal.h
// Add decompression-bomb guard to WebSocket message handling (CWE-409) (#22828)
// Frame size limits for protection against DoS and browser compatibility
#define WS_MAX_INCOMING_FRAME_SIZE  (20ULL * 1024 * 1024) // 20MB max incoming frame size
#define WS_MAX_OUTGOING_FRAME_SIZE  (4ULL * 1024 * 1024)  // 4MB max outgoing frame size
#define WS_MAX_DECOMPRESSED_SIZE    (200ULL * 1024 * 1024) // 200MB absolute cap

// Decompression-bomb guard (CWE-409): cap the decompressed size at a multiple
// of the compressed input, so a tiny payload cannot inflate toward
// WS_MAX_DECOMPRESSED_SIZE. WS_MIN_DECOMPRESSED_SIZE is a floor so small
// legitimate messages still decompress regardless of the ratio cap.
#define WS_MAX_DECOMPRESSION_RATIO  100ULL                 // max ratio
#define WS_MIN_DECOMPRESSED_SIZE    (1ULL * 1024 * 1024)   // 1MB floor

Source: GitHub Commit e3811f7

Detection Methods for CVE-2026-83599

Indicators of Compromise

Repeated inbound WebSocket handshakes to Netdata endpoints (/api/v*/ws) negotiating the permessage-deflate extension from untrusted sources.
Sudden growth in Netdata process resident memory (RSS) followed by OOM-killer events in kernel logs referencing the netdata process.
Loss of telemetry from monitored hosts coinciding with unexplained Netdata service restarts.

Detection Strategies

Alert on Netdata process termination or restart cycles that correlate with spikes in WebSocket connection counts.
Inspect reverse-proxy or load balancer logs for high volumes of WebSocket upgrade requests from a small number of source IPs.
Monitor oom_kill or cgroup memory limit events on hosts running Netdata to identify resource-exhaustion attempts.

Monitoring Recommendations

Track Netdata version inventory across the fleet and flag hosts running versions prior to 2.11.0.
Enable process-level memory ceilings via systemd MemoryMax= to bound blast radius and surface exhaustion attempts.
Forward Netdata access logs and host-level OOM events to a central log platform for correlation and alerting.

How to Mitigate CVE-2026-83599

Immediate Actions Required

Upgrade all Netdata agents and parents to version 2.11.0 or later, which introduces the WS_MAX_DECOMPRESSION_RATIO guard.
Restrict network exposure of the Netdata WebSocket port (default TCP/19999) to trusted management networks or VPN segments only.
Place Netdata behind an authenticating reverse proxy that terminates WebSocket connections and enforces rate limits.

Patch Information

The fix is included in Netdata Release v2.11.0. The patch adds a compressed-to-decompressed ratio check and a 1MB floor for small legitimate messages. Technical details are available in GitHub Pull Request #22828 and the GitHub Security Advisory GHSA-c8p4-cg3j-f4h2.

Workarounds

Front Netdata with a reverse proxy (for example, nginx or Caddy) that disables WebSocket compression on the upstream connection.
Apply firewall rules to allow WebSocket traffic to Netdata only from authorized Netdata Cloud or parent nodes.
Constrain the Netdata service with systemd resource limits so memory exhaustion does not destabilize the host.

bash

# systemd drop-in: bound Netdata memory to limit DoS impact
# /etc/systemd/system/netdata.service.d/override.conf
[Service]
MemoryMax=1G
MemoryHigh=768M
TasksMax=4096

# Apply changes
sudo systemctl daemon-reload
sudo systemctl restart netdata