Netdata CVE-2026-83603

Requires (1) local control of the low-privileged netdata service account on a host running Netdata prior to 2.10.4, (2) the setuid-root ndsudo helper present (default in affected packaged builds), and (3) fail2ban-client installed on the system, since the vulnerable command is fail2ban-client-status-socket. The attacker must be able to invoke ndsudo with a caller-controlled --socket_path and stand up a malicious UNIX socket. Limiting factors: no remote/network vector (AV:L) - a prior local foothold as the netdata account is mandatory - and hosts without fail2ban-client installed are not exploitable via this path.

This is a genuine high-priority local privilege-escalation-to-root issue, not a high-CVSS-but-low-risk case. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 8.4) accurately captures the shape: an attacker who already holds the low-privileged netdata service account can reach a setuid-root ndsudo helper whose caller-controlled --socket_path lets root's fail2ban-client connect to an attacker-owned UNIX socket, whose response is deserialized via pickle.loads() as root - a textbook unsafe-deserialization RCE-as-root. The Scope:Changed flag is correct because the netdata→root authority boundary is crossed. No EPSS score, KEV entry, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis'; however, the mechanism is well-understood and the fix diff is public (PR #22745 removes the caller-controlled socket path entirely and hardcodes it), which materially lowers the bar to reproduce. The A:N metric is arguably conservative - arbitrary root code execution can trivially destroy availability - so real impact may exceed the published vector. The one real limiter is that exploitation requires both prior local foothold as the netdata account AND fail2ban-client installed on the host.

An attacker who has already compromised or otherwise controls the low-privileged netdata service account (e.g. via a separate web/collector foothold) invokes the setuid-root ndsudo helper's fail2ban-client-status-socket command with --socket_path pointing at a malicious UNIX socket they control. Root's fail2ban-client connects, CSocket.receive() feeds the attacker-supplied bytes to pickle.loads(), and a crafted pickle payload executes arbitrary code as root. No public POC is referenced, but the patch diff and deserialization sink are public, making reproduction straightforward on hosts with fail2ban-client installed.