CVE-2026-83598: Netdata Windows Agent Privilege Escalation

CVE-2026-83598 Overview

Netdata is an open source observability tool used to monitor systems, containers, and applications. A local privilege escalation flaw affects the Netdata Windows Agent from version 2.0.0 through 2.10.3. During MSI repair, powershell.exe runs as SYSTEM without the -NoProfile flag and loads the invoking user's PowerShell profile from %USERPROFILE%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1. A low-privileged user who plants commands in that profile before initiating repair gains SYSTEM-level code execution. The issue is tracked as [CWE-269: Improper Privilege Management] and fixed in version 2.10.4.

Critical Impact
Any local user can escalate to SYSTEM privileges on Windows hosts running the affected Netdata Agent by writing to their own PowerShell profile and triggering an MSI repair.

Affected Products

Netdata Windows Agent 2.0.0 through 2.10.3
Netdata MSI installer package (netdata.wxs) on Windows
Fixed in Netdata 2.10.4

Discovery Timeline

2026-09-22 - CVE-2026-83598 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-83598

Vulnerability Analysis

The Netdata Windows Agent ships as an MSI package that supports the standard Windows Installer repair action. During repair, the installer invokes a custom action named NDCreateNewFiles that launches powershell.exe under the SYSTEM account to execute copy_files.ps1. The custom action string used a bare powershell.exe invocation without the -NoProfile switch. PowerShell therefore loaded the current user profile script from the initiator's %USERPROFILE%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 even though the process token belonged to SYSTEM.

Because a local, unprivileged user controls both the location and the contents of that profile file, any commands placed there run with SYSTEM authority the next time repair is triggered. The result is a reliable local privilege escalation primitive on hosts where the vulnerable agent is installed.

Root Cause

The root cause is improper privilege management in the WiX installer definition. The custom action executed a high-privilege interpreter without isolating its execution environment from the invoking user's profile, mixing SYSTEM-level authority with user-controlled configuration state.

Attack Vector

Exploitation requires local access with any interactive user account. The attacker writes malicious PowerShell commands into their own Microsoft.PowerShell_profile.ps1, then invokes msiexec /fa or the Programs and Features repair option against the Netdata MSI. When the deferred NDCreateNewFiles custom action runs, PowerShell auto-loads the profile and executes attacker code as SYSTEM.

text

             </InstallExecuteSequence>

             <!-- Add new files (stream.conf and netdata.conf) -->
-            <CustomAction Id="NDCreateNewFiles" Directory="USRLIBEXECNETDATADIR" ExeCommand='powershell.exe -NoProfile -ExecutionPolicy Bypass -NonInteractive -File "[USRLIBEXECNETDATADIR]\copy_files.ps1"' Execute="deferred" Return="ignore" Impersonate="no"/>
+            <SetProperty
+                Id="NDCreateNewFiles"
+                Value=""[System64Folder]WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -NonInteractive -File "[USRLIBEXECNETDATADIR]\copy_files.ps1""
+                Before="NDCreateNewFiles"
+                Sequence="execute"
+            />
+            <CustomAction
+                Id="NDCreateNewFiles"
+                BinaryRef="Wix4UtilCA_$(sys.BUILDARCHSHORT)"
+                DllEntry="WixQuietExec"
+                Execute="deferred"
+                Return="ignore"
+                Impersonate="no"
+            />
             <InstallExecuteSequence>
                 <Custom Action="NDCreateNewFiles" Before="InstallFinalize" />
             </InstallExecuteSequence>

Source: GitHub Commit d762782. The patch pins the interpreter to the fully qualified System64Folder PowerShell path and routes the command through WixQuietExec, ensuring the invocation is not resolved through the user's environment.

Detection Methods for CVE-2026-83598

Indicators of Compromise

Presence of Microsoft.PowerShell_profile.ps1 inside a standard user's Documents\WindowsPowerShell\ directory containing execution, download, or process-creation cmdlets.
powershell.exe child processes of msiexec.exe running under the NT AUTHORITY\SYSTEM account while the parent MSI is a Netdata package.
Unexpected SYSTEM-level process creation, service installation, or scheduled task creation immediately following an MSI repair event on Netdata hosts.

Detection Strategies

Alert on Windows Event ID 4688 where the parent process is msiexec.exe, the child is powershell.exe running as SYSTEM, and the command line lacks -NoProfile.
Correlate MsiInstaller events (Event IDs 1035, 1042) referencing the Netdata product code with subsequent SYSTEM-context PowerShell activity.
Hunt for recently modified Microsoft.PowerShell_profile.ps1 files under user profile directories on hosts that also have the Netdata Agent installed.

Monitoring Recommendations

Baseline which endpoints have Netdata Agent installed and continuously validate the installed version against 2.10.4 or later.
Monitor writes to %USERPROFILE%\Documents\WindowsPowerShell\ paths originating from standard user sessions.
Forward MSI installer, PowerShell script-block, and process creation logs to a central analytics tier for cross-source correlation.

How to Mitigate CVE-2026-83598

Immediate Actions Required

Upgrade the Netdata Windows Agent to version 2.10.4 or later on every affected host.
Inventory all interactive users on Netdata-managed Windows systems and inspect their PowerShell profile files for unauthorized content.
Restrict who can invoke MSI repair by enforcing least-privilege on interactive logon rights for monitored servers.

Patch Information

The fix is delivered in Netdata release v2.10.4 and implemented in Pull Request 22751. Full advisory details are documented in GHSA-8hxv-2mg6-ggw5. The patch replaces the vulnerable custom action with a fully qualified powershell.exe path invoked through WixQuietExec and preserves the -NoProfile flag.

Workarounds

Block non-administrative users from triggering MSI repair by removing the Netdata entry from Programs and Features exposure or restricting msiexec via AppLocker or Windows Defender Application Control.
Enforce PowerShell Constrained Language Mode for standard users to limit what a malicious profile script can execute.
Remove or write-protect existing Microsoft.PowerShell_profile.ps1 files that are not required for operational use.

bash

# Verify installed Netdata version on a Windows host (PowerShell)
Get-Package -Name "Netdata*" | Select-Object Name, Version

# List user PowerShell profiles that could be abused prior to patching
Get-ChildItem -Path "C:\Users\*\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1" -Force -ErrorAction SilentlyContinue