CVE-2026-83599 in Netdata
Summary
by MITRE • 09/22/2026
Netdata is an open source observability tool. Prior to 2.11.0, Netdata's unauthenticated WebSocket server negotiates permessage-deflate before authentication, and src/web/websocket/websocket-compression.c allows websocket_client_decompress_message() to grow decompressed output toward WS_MAX_DECOMPRESSED_SIZE without enforcing a compressed-to-decompressed ratio. Small highly compressed frames can therefore cause large server-side allocations, and repeated concurrent connections can exhaust memory and terminate monitoring. This vulnerability is fixed in 2.11.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Netdata prior to version 2.11.0 represents a critical resource exhaustion flaw rooted in the improper handling of WebSocket compression during the connection negotiation phase. As an open-source observability tool, Netdata relies heavily on real-time data ingestion via WebSockets, making its network-facing components prime targets for denial-of-service attacks. The core technical deficiency lies in the server's decision to negotiate permessage-deflate compression before performing any form of authentication or authorization checks. This architectural choice allows unauthenticated actors to initiate connections and trigger the decompression logic without first proving their legitimacy, thereby bypassing access controls that might otherwise limit resource consumption from malicious sources.
The specific technical flaw resides in the websocket_client_decompress_message function within src/web/websocket/websocket-compression.c. During normal operation, this function is responsible for inflating compressed data frames into a usable format for processing. However, the implementation fails to enforce a strict ratio between the size of the incoming compressed payload and the resulting decompressed output. In standard secure implementations, such as those adhering to best practices against zip bombs or compression-based denial-of-service attacks like CRIME or BREACH variants in HTTP contexts, servers typically limit the expansion factor or validate the integrity of the stream before allocating large buffers. By allowing the decompressed output buffer to grow toward WS_MAX_DECOMPRESSED_SIZE without validating whether the compressed input justifies such an allocation, Netdata becomes susceptible to extreme memory amplification attacks.
The operational impact of this vulnerability is severe and directly affects service availability. An attacker can craft small, highly compressed WebSocket frames that expand into massive amounts of data upon decompression. When these crafted frames are sent through multiple concurrent connections from unauthenticated clients, the server allocates significant portions of its available memory to hold the inflated payloads. This rapid consumption of system resources leads to memory exhaustion on the host machine running Netdata. As the operating system struggles with insufficient free RAM, it may begin swapping or killing processes, ultimately causing the Netdata service itself to terminate unexpectedly. This results in a complete loss of monitoring capabilities for the infrastructure being observed, creating a blind spot during critical operational periods and potentially masking other ongoing security incidents that would normally be detected by the observability platform.
From a classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write or CWE-400: Uncontrolled Resource Consumption, specifically manifesting as an application-level denial of service through memory exhaustion. In terms of adversary tactics, it maps to MITRE ATT&CK technique T1499: Endpoint Denial of Service, where the attacker's goal is not data theft but rather the disruption of critical services by overwhelming system resources. The lack of authentication prior to resource-intensive operations further exacerbates the risk, as it removes a fundamental layer of defense that would typically throttle or reject requests from untrusted sources before they consume significant computational power.
To mitigate this vulnerability and prevent similar issues in future deployments, upgrading to Netdata version 2.11.0 is mandatory, as this release addresses the compression handling logic by enforcing appropriate limits on decompression ratios. For environments where immediate patching is not feasible, administrators should implement network-level controls such as rate limiting or connection throttling at the load balancer or reverse proxy layer preceding Netdata. These measures can restrict the number of concurrent WebSocket connections from a single source IP address and limit the size of incoming payloads before they reach the application server. Additionally, configuring Web Application Firewalls to inspect for anomalous compression patterns in WebSocket traffic can provide an additional layer of defense against exploitation attempts targeting this specific resource exhaustion flaw.