Summary
UTMStack before 11.2.16 does not adequately authorize commands sent through the UTMIncidentCommandWebsocket STOMP destination. Any authenticated user, including users without an administrative role, may be able to execute operating-system commands on connected monitoring agents.
Affected context
The vulnerability occurs in UTMStack deployments where the UTMIncidentCommandWebsocket processes commands received through the /command/{hostname} STOMP destination and forwards them over gRPC to connected agents. Risk is highest when authenticated users have access to the messaging endpoint and agent processes operate with elevated privileges, such as root or SYSTEM.
Exploit preconditions
- Attack surface: The authenticated STOMP command destination exposed by the UTMStack application
- Required access: Any valid authenticated UTMStack user account; elevated role privileges may not be required
- Target selection: A connected monitoring agent identified through the command destination
- Trigger point: Command processing in
UTMIncidentCommandWebsocket.processCommand() - Why exploitation is possible: The handler forwards supplied commands without consistently enforcing role authorization or an approved command allowlist
Why this happens
The underlying flaw is an authorization failure in a command execution handler. The application accepts a command from an authenticated session and forwards it to an agent without verifying that the user is permitted to perform that operation or that the command belongs to an approved set. This behavior maps to CWE-862, Missing Authorization, because authentication is treated as sufficient access control for a privileged action.
Potential impact
- An attacker may execute arbitrary operating-system commands on connected agents
- Compromised agents could expose monitored systems, credentials, or collected telemetry
- Commands may run with root, SYSTEM, or another highly privileged service identity
- An attacker could alter monitoring behavior, disrupt operations, or move laterally
- The UTMStack environment and connected endpoints could be used for broader compromise
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the command
handling boundary and reducing the privileges available to agent processes.
Common defensive patterns include:
- Require explicit, role-based authorization for every command request
- Apply deny-by-default command allowlists for operations exposed through automation
- Bind authorization checks to the selected hostname and the user's permitted scope
- Separate authentication from authorization and reject requests that lack an approved capability
- Run agents with the minimum operating-system privileges needed for their functions
- Prefer narrowly scoped service actions over unrestricted operating-system command execution
- Protect STOMP and gRPC channels with strong session, transport, and endpoint controls
- Record command requests, authorization decisions, and agent execution results for accountability
How teams detect issues like this
Detection and review approaches may include:
- Static analysis searches for websocket or message handlers that invoke process, shell, or gRPC execution without nearby authorization checks
- Code review checks confirming role, capability, tenant, and hostname-scope validation before command forwarding
- Tests that exercise every user role against privileged command destinations and verify deny-by-default behavior
- Policy enforcement requiring command allowlists for automation endpoints
- Runtime monitoring for unusual command volume, unexpected requesting identities, or commands issued to unrelated agents
- Neutral automated code-review or security-scanning tools can help identify missing access-control checks, but findings should be validated in deployment context
