Summary
Netdata's setuid-root ndsudo helper can allow the low-privileged netdata service account to select a UNIX socket used by fail2ban-client. When the returned socket data is processed through unsafe Python pickle deserialization, an attacker who can control that socket may execute code with root privileges on systems where fail2ban-client is installed.
Affected context
The vulnerability occurs in Netdata deployments that use the setuid-root ndsudo helper and have fail2ban-client available. Risk is present when the low-privileged netdata account can invoke the fail2ban-client-status-socket helper with a caller-controlled socket path and cause root-run client logic to consume attacker-controlled data.
Exploit preconditions
- Attack surface: The Netdata
ndsudohelper and itsfail2ban-client-status-socketcommand - Required access: Ability to act as or influence the low-privileged
netdataservice account, plus the ability to provide or control a malicious UNIX socket - Trigger point: Root invokes
fail2ban-clientagainst the attacker-selected socket - Why exploitation is possible: Response data is passed to
pickle.loads(), which can deserialize attacker-controlled Python objects and execute code with the helper's root privileges
Why this happens
The issue combines inadequate control over a privileged resource path with unsafe deserialization. The setuid-root helper accepts a caller-controlled UNIX socket location, mapping to CWE-73: External Control of File Name or Path, while the fail2ban client uses pickle.loads() on data received from that location. Deserializing untrusted pickle data can invoke arbitrary object behavior, which maps to CWE-502: Unsafe Deserialization.
Potential impact
- An attacker may execute arbitrary code with root privileges
- The host operating system could be compromised
- Netdata credentials, configuration, and collected telemetry could be exposed or altered
- Attackers could disable monitoring or tamper with security controls
- The compromised host could be used for lateral movement or persistence
General mitigation guidance
Mitigation generally focuses on removing trust in caller-supplied socket paths and eliminating unsafe deserialization of IPC responses.
Common defensive patterns include:
- Restricting privileged helpers to a fixed, validated set of socket locations
- Avoiding pickle for data exchanged across privilege boundaries
- Using authenticated, narrowly scoped, and non-executable serialization formats
- Separating root-level operations from inputs controlled by service accounts
- Applying least privilege and minimizing setuid-root helper functionality
- Limiting access to UNIX socket directories and enforcing appropriate ownership and permissions
- Isolating observability services and monitoring unexpected privileged helper invocations
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis rules identifying
pickle.loads()or equivalent deserialization of IPC or externally sourced data - Code review checks for setuid helpers that accept caller-controlled paths
- Searches for privileged subprocesses using arguments derived from low-privilege service input
- Runtime monitoring of
ndsudoexecutions, unusual socket paths, and unexpected root child processes - Policy enforcement that prohibits unsafe serialization formats across privilege boundaries
- Automated security review tools that flag dangerous deserialization and path-control patterns
