CVE-2026-82042: Critical Authentication Bypass in UTMStack's InternalApiKeyFilter

Overview

UTMStack, an open-source SIEM (Security Information and Event Management) platform, is affected by a critical authentication bypass vulnerability tracked as CVE-2026-82042. The flaw carries a CVSS 3.1 score of 9.8 (Critical) and a CVSS 4.0 score of 9.3 (Critical), and was published on October 2, 2026.

The vulnerability lives in InternalApiKeyFilter, the component responsible for validating a custom Utm-Internal-Key HTTP header against the value of the INTERNAL_KEY environment variable. That header exists so UTMStack's own sibling containers — agent-manager, plugins, the installer/updater — can talk to each other without a full JWT handshake. The problem is architectural rather than cryptographic: the filter honors a matching key on any endpoint, with no path restriction and no role-based context check. Anyone who can present the correct key value is treated as a fully authenticated, fully authorized internal caller — including on administrative routes — with no username, password, or JWT ever required.

CVE-2026-82042 was disclosed alongside six other UTMStack CVEs (CVE-2026-82039 through CVE-2026-82045), all patched together in v11.2.16. The most severe of the group, CVE-2026-82041 (CVSS 9.9), is a missing-authorization flaw on the /command/{hostname} STOMP websocket that can lead to remote code execution on monitored endpoints — CosmicBytez Labs is covering that one separately, but it's worth knowing the two land in the same release and, per public write-ups of the disclosure, can plausibly be chained (an attacker who forges the internal-key header to gain admin access is then well-positioned to reach the websocket command path too). The researcher credited for this disclosure cluster is Adam Nurudini (QwesiRED).

Notably, UTMStack's public v11.2.16 release notes describe only alert-noise reduction work (Windows auth alerts, FortiGate brute-force consolidation, and similar) and make no mention of the security fixes — consistent with the project not calling out security-relevant changes in its public changelog. The technical detail in this advisory is drawn from the NVD record, the associated GitHub Security Advisory (GHSA-phx4-fx7q-vfw9), a VulnCheck advisory, and the public fix commit.

Technical Details

How It Works

What InternalApiKeyFilter does

UTMStack ships as a set of cooperating containers — the core API, an agent-manager, a plugins service, and an installer/updater, among others. Rather than issuing those internal services full user credentials, UTMStack lets them authenticate to each other with a shared secret: the INTERNAL_KEY environment variable, presented on requests via the Utm-Internal-Key HTTP header. InternalApiKeyFilter sits in front of the API and, when it sees a header value matching INTERNAL_KEY, treats the request as coming from a trusted internal caller.

Root cause

NVD's description and the GitHub Security Advisory agree on the shape of the bug: the filter applied this check globally, across every endpoint, with no path allowlist and no role-based context. A constant-time comparison was reportedly not in place prior to the fix either (sources differ slightly on which specific omission is primary — the GHSA and VulnCheck language emphasizes the combination of "no path restrictions, no constant-time comparison, no rate limiting, no audit logging"). Whichever omission is weighted most heavily, the practical effect is the same: a request carrying a valid Utm-Internal-Key header is honored as administrative, regardless of which endpoint it hits, and regardless of whether the caller holds any legitimate user credentials.

An attacker only needs the INTERNAL_KEY value itself — obtainable through source code exposure, a leaked .env or configuration file, container memory/log exposure, or simply a default/unrotated value carried over from deployment. Once in hand, that single string outranks the platform's entire JWT-based authentication layer.

Attack chain

1. Attacker obtains the INTERNAL_KEY value (source exposure, leaked
   config/.env file, log or memory exposure, or an unrotated
   default from initial deployment).
2. Attacker crafts an HTTP request to any UTMStack API endpoint —
   including admin-only routes — adding the header:
     Utm-Internal-Key: <stolen key value>
3. InternalApiKeyFilter matches the header against INTERNAL_KEY.
   Prior to 11.2.16, a match on ANY path short-circuits normal
   JWT authentication and authorization checks entirely.
4. The request is processed as a fully trusted internal service
   call, regardless of the endpoint it actually targets.
5. Attacker now holds administrative API access: create accounts,
   manage users, exfiltrate SIEM data, or modify detection/security
   rules — without ever presenting a username, password, or JWT.

The fix in 11.2.16

The public fix commit (4e7a727c3b8d8e2ad020d3b4f982a6d085dbecdd, part of a single commit patching the full CVE-2026-82039–82045 cluster) hardens InternalApiKeyFilter.java with several layered controls, per third-party analysis of the diff:

1. Path allowlisting — the internal key is now honored only on a short list of specific machine-to-machine routes used by sibling containers (agent-manager, plugins, installer/updater); any other path falls through to normal JWT authentication.
2. Constant-time comparison — the key check now uses MessageDigest.isEqual() in place of a plain equality comparison, closing a timing side-channel.
3. Optional CIDR restriction — a new INTERNAL_KEY_ALLOWED_CIDRS environment variable lets operators restrict which source IPs may present the internal key at all.
4. Audit logging — accepted internal-key requests are now logged with caller IP, method, and path.

Related disclosure

CVE-2026-82041 (CVSS 9.9), disclosed the same day in the same product, is a missing-authorization flaw on the /command/{hostname} STOMP websocket that can lead to remote code execution on monitored endpoints. It's part of the same seven-CVE batch fixed in v11.2.16. CosmicBytez Labs is treating it as a separate advisory, but operators patching for CVE-2026-82042 should upgrade to 11.2.16 regardless, since that single release addresses both.

Impact Assessment

Recommendations

For UTMStack operators and administrators

1. Upgrade to UTMStack 11.2.16 or later immediately. This is the vendor-shipped fix for CVE-2026-82042 (and six related CVEs); there is no supported workaround for versions before 11.2.16.
2. Rotate the INTERNAL_KEY environment variable as part of (and after) the upgrade — assume any prior value may have been exposed, since the vulnerability's prerequisite is simply knowing that string.
3. Audit logs and configuration for any .env files, CI artifacts, container logs, or backups that may have exposed INTERNAL_KEY in plaintext, and rotate it again if found.
4. If upgrading is not immediately possible, restrict network access to the UTMStack API to trusted internal ranges only, and review the new INTERNAL_KEY_ALLOWED_CIDRS option once patched to further scope which source IPs may ever present the internal-service header.

For security and AppSec teams

1. Treat shared-secret, header-based internal-service auth as a first-class attack surface. This bug is a reminder that an internal trust mechanism applied without path or role scoping is equivalent to a master key for the whole API.
2. Review any self-hosted SIEM or security tooling (UTMStack or otherwise) for similar internal-API-key patterns, and confirm they're scoped to specific routes rather than applied globally.
3. Monitor for Utm-Internal-Key headers arriving from unexpected source IPs performing administrative actions, particularly before the audit-logging improvements in 11.2.16 are deployed.

For MSSPs and managed security providers running UTMStack

1. Prioritize this patch across every managed tenant. A SIEM with admin-level auth bypass risks client data exposure and loss of trust in its own alerting.
2. Confirm patch status and INTERNAL_KEY rotation per deployment rather than assuming a fleet-wide update — self-hosted SIEM instances are easy to miss in routine patch cycles.

Key Takeaways

1. CVE-2026-82042 is a CVSS 9.8 Critical authentication bypass (CWE-306) in UTMStack's InternalApiKeyFilter, affecting all versions before 11.2.16.
2. The root cause is architectural: a shared INTERNAL_KEY/Utm-Internal-Key header mechanism meant for internal container-to-container trust was honored on every API endpoint with no path or role restriction — anyone holding the key gets full admin access, no JWT required.
3. The fix in v11.2.16 adds path allowlisting, constant-time key comparison, optional CIDR restriction, and audit logging to InternalApiKeyFilter.java.
4. UTMStack's public release notes for 11.2.16 do not mention this fix (or the six related CVEs it was bundled with) — the technical detail here comes from NVD, GHSA-phx4-fx7q-vfw9, VulnCheck, and the public fix commit, not the vendor's changelog.
5. A related, more severe flaw — CVE-2026-82041 (CVSS 9.9, websocket RCE) — was disclosed the same day in the same product and fixed in the same release; operators should patch for both regardless of which one prompted the upgrade.
6. No public proof-of-concept has been indexed and the CVE is not in CISA's KEV catalog as of publication, but the combination of trivial exploitation (a single HTTP header) and administrative impact warrants immediate patching and INTERNAL_KEY rotation.

Sources

• NVD — CVE-2026-82042
• GitHub Security Advisory — GHSA-phx4-fx7q-vfw9
• VulnCheck — UTMStack Authentication Bypass via InternalApiKeyFilter
• GitHub — UTMStack v11.2.16 release
• GitHub — UTMStack fix commit 4e7a727
• DEV Community — UTMStack cluster: 7 CVEs, peak CVSS 9.9 missing auth on STOMP command websocket

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