Summary
A privilege escalation vulnerability in the Netdata Windows Agent MSI repair process causes PowerShell to run as SYSTEM while loading a profile controlled by the low-privileged user who initiated the repair. An attacker who can place commands in that profile before repair may execute code with SYSTEM privileges on the Windows host.
Affected context
The issue occurs in affected Netdata Windows Agent installations when an MSI repair is initiated by a low-privileged user. During repair, PowerShell runs with SYSTEM privileges without profile suppression and may load the initiating user's %USERPROFILE%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 file. Exploitation depends on the user being able to modify that profile before the repair operation.
Exploit preconditions
- Attack surface: Netdata Windows Agent MSI repair workflow
- Required access: Low-privileged access to the Windows host and permission to modify the user's PowerShell profile
- Trigger point: Execution of the Netdata MSI repair process
- Why exploitation is possible: A SYSTEM-level PowerShell process loads a profile from a lower-privileged user's profile directory, allowing user-controlled commands to run in a more privileged security context
Why this happens
The underlying flaw is an unsafe privilege boundary in the MSI repair process. A process running as SYSTEM launches PowerShell without disabling profile loading, allowing PowerShell to consume user-controlled initialization content from the initiating account. This behavior maps primarily to CWE-269: Improper Privilege Management because privileged execution is combined with an untrusted lower-privilege input source. It is also related to CWE-427: Uncontrolled Search Path Element, since executable behavior is influenced by content resolved from an insufficiently trusted profile location.
Potential impact
- An attacker may execute arbitrary commands with SYSTEM privileges
- The host could be fully compromised
- Local security controls or services may be altered
- Credentials, application data, or observability data could be exposed
- The compromised system could be used for lateral movement
General mitigation guidance
Mitigation generally focuses on preventing privileged processes from loading user-controlled PowerShell profiles or other initialization content.
Common defensive patterns include:
- Disable profile loading for privileged, non-interactive PowerShell execution
- Ensure privileged repair workflows use trusted, explicitly resolved resources
- Separate maintenance operations from user-writable directories
- Apply least privilege to installer and repair operations where practical
- Restrict write access to PowerShell profile locations and monitor changes
- Use application control and endpoint policies to limit unauthorized script execution
- Validate that privileged processes do not inherit unsafe user-controlled environment or search-path data
How teams detect issues like this
Organizations can look for:
- Static analysis rules identifying privileged PowerShell execution without profile suppression
- Code review signals where SYSTEM services or installers consume files from user-writable locations
- MSI repair and installer telemetry showing elevated PowerShell child processes
- File-integrity monitoring for changes to PowerShell profile files before repair activity
- Endpoint detection rules correlating low-privileged user activity with subsequent SYSTEM-level script execution
- Policy enforcement that blocks or audits privileged processes loading user-controlled initialization files
