CVE-2026-82041: Missing Authorization in UTMStack's Incident Command WebSocket Enables Authenticated RCE

Overview

UTMStack, an open-source SIEM/XDR platform that unifies log correlation, threat intelligence, and automated incident response for monitored endpoints, is affected by a critical missing-authorization vulnerability tracked as CVE-2026-82041. The flaw carries a CVSS 3.1 score of 9.9 (Critical) and was published on October 2, 2026, per NVD.

UTMStack's architecture pairs a central server with lightweight agents deployed on monitored endpoints. Those agents collect logs and, critically, execute local and remote incident-response commands — often with elevated privileges (root on Linux, SYSTEM on Windows) — so that analysts can take automated containment actions (isolating a host, killing a process, and similar) directly from the UTMStack console. Per NVD, the vulnerability lives in UTMIncidentCommandWebsocket.processCommand(), the handler bound to the STOMP /command/{hostname} destination: it forwards supplied commands to the named agent without applying any role check or command allowlist first. The result is that any authenticated user, regardless of role, can send arbitrary commands to any connected agent/hostname, enabling remote code execution or full host takeover via the websocket channel.

CVE-2026-82041 was disclosed and fixed as part of a larger batch of UTMStack issues patched together in v11.2.16, most notably CVE-2026-82042 (CVSS 9.8, an authentication-bypass via the Utm-Internal-Key header). CosmicBytez Labs is covering CVE-2026-82042 separately — this advisory addresses CVE-2026-82041 only, but operators should assume both apply if running an affected version, since the same release fixes both. Beyond the NVD record, the fix commit, and a handful of independent CVE aggregator write-ups, no vendor advisory or in-depth researcher analysis was found at the time of publication; this advisory is written from those sources and will be updated if more detail becomes available.

Technical Details

How It Works

What the incident command WebSocket does

UTMStack deploys agents — log collectors — on every endpoint it monitors. Beyond shipping logs back to the central server for correlation, these agents can also carry out incident-response commands issued from the UTMStack console: actions like isolating a compromised host or terminating a process, which generally require the agent process to run with elevated local privileges (root or SYSTEM) to be effective. The console-to-server leg of that workflow runs over STOMP, a text-based messaging protocol layered on WebSockets, with commands published to a destination scoped by hostname: /command/{hostname}. The server, in turn, relays the command onward to the targeted agent over gRPC.

Root cause

According to NVD, UTMIncidentCommandWebsocket.processCommand() — the handler mapped to /command/{hostname} — applies no role check and no command allowlist before forwarding the supplied command to the target agent. The server only confirms that the caller holds some authenticated session; it never verifies that the account's role entitles it to issue operational commands, let alone to the specific hostname named in the destination. Any authenticated user who can open a STOMP connection to the server and publish to that destination gets the same outcome as a fully privileged analyst: the message is treated as an authorized incident-response command and relayed to the agent.

Attack chain

1. Attacker obtains any authenticated UTMStack session — any role,
   including a low-privilege account.
2. Attacker opens a STOMP/WebSocket connection to the UTMStack
   server and publishes a command to /command/{hostname} for a
   target hostname running a connected agent.
3. UTMIncidentCommandWebsocket.processCommand() accepts the message
   without checking the caller's role or validating the command
   against an allowlist.
4. The server forwards the attacker-supplied command to the target
   agent over gRPC exactly as it would a legitimate, analyst-issued
   incident-response action.
5. The agent executes the command with the elevated privileges
   (root / SYSTEM) it normally uses for authorized response actions,
   giving the attacker code execution on that endpoint.

Why the blast radius is every monitored endpoint

Because the vulnerable destination is parameterized only by hostname — not scoped to hosts the caller is actually permitted to manage — a single low-privilege UTMStack account is enough to target any agent the server knows about. In a typical deployment, that agent footprint spans the organization's servers and workstations, so exploitation does not stop at the attacker's own account privileges: it extends to full compromise of every endpoint UTMStack monitors.

Part of a larger UTMStack disclosure batch

CVE-2026-82041 was fixed in the same v11.2.16 release as several other UTMStack vulnerabilities, including CVE-2026-82042 (CVSS 9.8) — an authentication bypass via the Utm-Internal-Key header that grants full administrative API access. CosmicBytez Labs is tracking CVE-2026-82042 in a separate advisory; both are independently exploitable and both are resolved by the same upgrade.

Impact Assessment

Recommendations

For UTMStack operators and administrators

1. Upgrade to UTMStack v11.2.16 or later immediately. This is the vendor-shipped fix for CVE-2026-82041; there is no supported workaround for versions before 11.2.16.
2. Rotate internal/API keys (including the Utm-Internal-Key used elsewhere in the platform) after upgrading, given this vulnerability was disclosed alongside a related authentication-bypass issue (CVE-2026-82042) in the same release.
3. Audit incident-command and agent logs for commands issued by accounts that should not have had operational/response permissions, and for commands targeting hostnames outside an account's normal scope.
4. Review account roles and credential hygiene across your UTMStack console — until patched, every authenticated account, regardless of assigned role, was equivalent to a full incident-response operator.

For SOC and security teams

1. Treat UTMStack (or any SIEM/XDR console) as a high-value target in its own right — a platform with standing, privileged command access to every monitored endpoint is a single point of compromise for the whole fleet.
2. Apply the same patch urgency to security tooling that you'd apply to production infrastructure. A CVSS 9.9 missing-authorization bug in the tool that holds root/SYSTEM-level command access to your estate is a direct path to full compromise.
3. Monitor for anomalous incident-response commands issued outside expected analyst workflows, particularly commands originating from recently created or low-privilege accounts.

For MSSPs and multi-tenant UTMStack deployments

1. Prioritize this patch across every client instance — the "any authenticated user, any role" nature of the flaw means even a client-facing, read-only account is enough to pivot into command execution on that client's monitored endpoints.
2. Confirm tenant isolation after upgrading — verify that one tenant's authenticated users cannot reach command destinations tied to another tenant's hostnames.

Key Takeaways

1. CVE-2026-82041 is a CVSS 9.9 Critical missing-authorization vulnerability (CWE-862) in UTMStack's UTMIncidentCommandWebsocket.processCommand() handler, affecting versions before 11.2.16.
2. The root cause is the STOMP /command/{hostname} destination forwarding commands to connected agents with no role check and no command allowlist, so any authenticated session — regardless of role — is treated as an authorized incident-response operator.
3. Because agents frequently run with root/SYSTEM privileges to perform automated response actions, exploitation amounts to an authenticated-to-root pivot on any monitored endpoint, not just hosts the attacker's account is meant to manage.
4. This CVE was disclosed and fixed alongside other UTMStack issues — notably CVE-2026-82042, an authentication bypass — in the same v11.2.16 release; organizations should patch for both.
5. NVD lists no confirmed public exploit and the flaw is not in CISA's KEV catalog as of October 2, 2026, but the low bar for exploitation (any authenticated account, no user interaction) warrants urgent patching regardless.
6. The maintainers fixed the issue in v11.2.16; all pre-11.2.16 installations should upgrade immediately.

Sources

• NVD — CVE-2026-82041
• GitHub — utmstack/UTMStack
• GitHub — utmstack/UTMStack release v11.2.16
• GitHub — utmstack/UTMStack fix commit

CosmicBytez Labs will update this advisory if UTMStack or independent researchers publish additional technical detail on CVE-2026-82041.