UTMStack EUVD-2026-91797

Exploitation requires the attacker to possess the exact value of the INTERNAL_KEY environment variable and supply it in the 'Utm-Internal-Key' HTTP header; in UTMStack versions before 11.2.16 the InternalApiKeyFilter accepts this key on ANY endpoint (no path allowlist), with no constant-time comparison, rate limiting, or audit logging, so once the key is known a single request against any admin API grants full administrative authentication with no user account, JWT, or user interaction. The primary limiting factor is obtaining the key itself - it is a shared machine-to-machine secret, so realistic attack paths involve a leaked/default/weak key, read access to the deployment environment, or compromise of a sibling container (agent-manager, plugins, installer/updater) that legitimately holds it. The patched 11.2.16 build adds a fixed route allowlist, constant-time comparison, audit logging, and an optional INTERNAL_KEY_ALLOWED_CIDRS source-IP restriction.

All provided signals point to a genuinely severe, high-priority flaw, with one important caveat around the exploitation prerequisite. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, 9.3) describes remote, low-complexity, unauthenticated exploitation yielding full confidentiality, integrity, and availability impact - consistent with the CWE-306 (Missing Authentication) classification and the description of complete administrative API takeover. The InternalApiKeyFilter accepting the key on any path with no constant-time comparison, rate limiting, or audit logging confirms a trivially abusable design once the key is known. The critical nuance: the CVSS vector encodes PR:N, but the description explicitly states the attacker must present 'a valid Utm-Internal-Key header matching the INTERNAL_KEY environment variable value' - i.e., possession of a shared secret is a real precondition, so 'unauthenticated' here means no user account/JWT is required, NOT that no secret is needed. This is a meaningful limiting factor the raw PR:N score understates. No EPSS score, CISA KEV listing, or POC indicator was provided in the input; per precision rules this is 'no public exploit identified at time of analysis.' A patch is confirmed available from the vendor. Net assessment: a real and serious priority for UTMStack operators, tempered by the key-knowledge prerequisite that makes mass untargeted exploitation less likely than the headline 9.3 suggests - most realistic against insiders, attackers with access to leaked/default/weak INTERNAL_KEY values, or those who can read it from a compromised sibling container or misconfigured environment.

A remote attacker who has obtained the deployment's INTERNAL_KEY value (e.g., from a leaked configuration, default/weak value, or a compromised adjacent container) sends an HTTP request to any UTMStack administrative API endpoint with the header 'Utm-Internal-Key: <key>'. Because the pre-11.2.16 InternalApiKeyFilter honors this key on every path without restriction, the request is authenticated with full administrative authority, letting the attacker create admin accounts, manage users, exfiltrate security data, and alter detection rules. No public exploit was identified in the provided data, but the technique is straightforward to reproduce given the key.