NSSM version 2.24 is vulnerable to local privilege escalation when installed with insecure file permissions, allowing low-privileged users to replace the executable and run malicious code as SYSTEM. The vulnerability stems from Weak Service Permissions where attackers modify the service binary path, requiring remediation via strict Access Control List (ACL) configuration on the executable directories. For more information, visit the official nssm.cc documentation.
The payload runs as SYSTEM . The attacker now has a high-integrity shell, can dump LSASS for credentials, move laterally, or disable security tools. nssm-2.24 privilege escalation
NSSM 2.24 does not enforce a restrictive DACL (Discretionary Access Control List) on created services. Instead, it relies on Windows defaults, which may allow SERVICE_CHANGE_CONFIG to non-admin users when the service is created during an administrative session but without explicit security hardening. NSSM version 2
The privilege escalation vulnerability in 2.24 stems primarily from or weak permissions on the service executable . The payload runs as SYSTEM
Later versions of NSSM (2.24.1, 2.25, and above) introduced critical safeguards:
Before dissecting the vulnerabilities, it is essential to understand what NSSM is and why version 2.24 is so pervasive. NSSM, short for Non-Sucking Service Manager, is a service helper program. It solves a persistent problem in Windows: many simple applications and scripts are not designed to run as system services. NSSM bridges that gap by acting as a wrapper. It starts any application or command line script as a Windows service, automatically restarts it if it fails, and provides service-specific environment variables and logging capabilities. Unlike Microsoft’s own srvany.exe , NSSM is more robust, easier to configure, and remains actively maintained.
NSSM 2.24 itself creates a service. If the binary file of the application that NSSM is managing has weak permissions (e.g., Users: Modify or Users: Full Control ), a non-privileged user can replace the application executable with a payload. NSSM is configured to run C:\Service\App.exe . The directory C:\Service\ is writable by standard users. The user replaces App.exe with a malicious executable.