CVE-2026-83598 in Netdata
Summary
by MITRE • 09/22/2026
Netdata is an open source observability tool. From rom 2.0.0 until 2.10.4, during Netdata Windows Agent MSI repair, powershell.exe runs as SYSTEM without -NoProfile and loads %USERPROFILE%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 from the low-privileged user who initiated repair. Commands placed in that profile before repair therefore execute with SYSTEM privileges. This vulnerability is fixed in 2.10.4.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified within Netdata versions ranging from 2.0.0 to 2.10.4 represents a significant privilege escalation flaw rooted in the improper handling of PowerShell execution contexts during system repair operations on Windows environments. As an open-source observability tool, Netdata installs agents that require elevated privileges for comprehensive monitoring capabilities. However, the installation mechanism relies on Microsoft Installer (MSI) processes which invoke repairs or modifications to existing installations. During these specific maintenance windows, the installer triggers a PowerShell script execution context without adhering to secure configuration defaults. Specifically, the process launches powershell.exe with SYSTEM-level integrity levels but fails to include the -NoProfile parameter in its command line arguments. This omission is critical because it instructs the shell to load the user-specific profile scripts located at %USERPROFILE%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 before executing any installer commands.
This technical flaw creates a dangerous attack vector where low-privileged users can influence high-privilege operations through file system manipulation. Since the PowerShell session loads the profile of the user who initiated the repair, any malicious code placed within that specific Microsoft.PowerShell_profile.ps1 file will be executed by the subsequent SYSTEM-level process. An attacker with local access to a machine running an affected version of Netdata can simply edit their own PowerShell profile script to include arbitrary commands or payloads. When they subsequently trigger a repair operation for the Netdata agent, whether through the control panel or command line, the installer inadvertently executes this malicious code under the context of NT AUTHORITY\SYSTEM. This effectively bypasses standard access controls and allows an unprivileged user to gain full administrative rights over the host system without requiring additional exploitation techniques such as buffer overflows or kernel exploits.
The operational impact of this vulnerability is severe, particularly in multi-user environments where local account creation policies are permissive. It falls squarely under CWE-250, which describes execution with unnecessary privileges, and aligns with MITRE ATT&CK technique T1068, specifically the sub-technique for exploitation of trusted services or processes to escalate privileges. The attacker does not need to exploit a complex software bug in Netdata itself but rather leverages the legitimate behavior of PowerShell profile loading combined with an insecure execution flag. This makes detection difficult as the actions appear to be part of normal system administration activities, yet they result in complete compromise of the host's security posture. Once SYSTEM privileges are obtained, the attacker can install rootkits, dump credential hashes from memory using tools like Mimikatz, modify registry keys for persistence, and move laterally across the network with unrestricted access.
Mitigation strategies must address both immediate remediation and long-term hardening practices. The primary solution is to upgrade Netdata immediately to version 2.10.4 or any subsequent release where this issue has been patched by ensuring that PowerShell invocations during installation processes explicitly use the -NoProfile flag, thereby preventing the loading of user-specific scripts with elevated privileges. In environments where upgrading is not immediately feasible, administrators should enforce strict Group Policy settings that restrict access to the %USERPROFILE%\Documents\WindowsPowerShell directory for standard users or disable automatic profile execution entirely via registry modifications such as setting ExecutionPolicy to RemoteSigned and ensuring no custom profiles are loaded during service installations. Additionally, implementing application control policies like Windows Defender Application Control can prevent unauthorized scripts from executing in privileged contexts, providing a layer of defense-in-depth against this specific abuse vector. Regular auditing of installed software versions and monitoring for unusual PowerShell activity associated with installer processes can also aid in early detection of such privilege escalation attempts.