Table of contents
21
Read this in 30 seconds: CVE-2026-82042 and CVE-2026-82041 are two critical flaws in UTMStack, an open-source SIEM, and the fix is public in its repository.
- CVE-2026-82042 turns one shared secret into admin. Send the right
Utm-Internal-Keyheader and the old code authenticated you as the first active admin on every endpoint, with no rate limit and no audit log.- CVE-2026-82041 lets any logged-in user run commands on your endpoints. The incident-response websocket had no role check, and UTMStack agents commonly run as root or SYSTEM.
- It isn’t known to be exploited. Neither CVE is in CISA’s KEV catalog, and the 9.8 score for CVE-2026-82042 assumes the attacker already has the key.
- The advisories say “before 11.2.16,” but git shows the fix in 11.2.14. That release shipped September 25, and its notes mention patches for disclosed CVEs.
- We read the patched code and found two things worth checking. We haven’t tested either, and we explain both below.
A SIEM exists to see everything on your network, which makes the keys to its own admin API worth more than almost any other secret you hold.
UTMStack published seven CVEs on October 2, 2026, all patched by a single commit. Two of them, CVE-2026-82042 and CVE-2026-82041, carry critical scores, and the code that fixed them is public, so we can show exactly what was wrong instead of guessing.
Here’s the vulnerable code behind CVE-2026-82042, the fix, what the advisories get wrong about versions, and what to check on your own deployment.
UTMStack is an open-source SIEM, SOAR and compliance platform under the AGPL-3.0 license. It collects logs from across an organization, correlates them into alerts, and can push response actions to agents installed on endpoints.
That design is why these bugs matter more than their product’s size suggests. A SIEM’s admin API can read every log, change every detection rule, and create accounts. Its agents, installed across the fleet, often run with the highest privileges. Whoever controls the SIEM controls what defenders can see, and per the advisory for CVE-2026-82041, can run commands where the agents live. That’s the context for reading CVE-2026-82042.
A single commit, 4e7a727c, patched seven CVEs numbered CVE-2026-82039 through CVE-2026-82045. Its commit message names each one. These are the two that carry critical scores:
| CVE-2026-82042 | CVE-2026-82041 | |
|---|---|---|
| What it is | Internal API key accepted as admin on any endpoint | No role check on the incident-response command websocket |
| CWE | CWE-306 | CWE-862 |
| CVSS 3.1 (in the NVD record) | 9.8 (AV:N/AC:L/PR:N) | 9.9 (AV:N/AC:L/PR:L/S:C) |
| VulnCheck CVSS 4.0 | 9.3 | 6.5 |
| Needs | The shared INTERNAL_KEY value | Any authenticated account |
| Credit | Adam Nurudini (QwesiRED) | Adam Nurudini (QwesiRED) |
The scores for CVE-2026-82041 disagree sharply, 9.9 under CVSS 3.1 and 6.5 under CVSS 4.0. The 3.1 vector counts a changed scope because the commands land on other systems, while the 4.0 vector rates the vulnerable system itself as unaffected. Neither is wrong, they just measure different things. Both advisories are published by VulnCheck: CVE-2026-82042 and CVE-2026-82041.
This is UTMStack’s InternalApiKeyFilter as of v11.2.13, trimmed to the lines that matter:
String apiKeyHeader = request.getHeader("Utm-Internal-Key");
String envApiKey = System.getenv("INTERNAL_KEY");
// ...
} else if (StringUtils.hasText(apiKeyHeader) && apiKeyHeader.equals(envApiKey)) {
UsernamePasswordAuthenticationToken authentication =
internalApiKeyProvider.getAuthentication(apiKeyHeader);
SecurityContextHolder.getContext().setAuthentication(authentication);
apiKeyHeaderInUse = true;
}If the header equals the INTERNAL_KEY environment variable, the filter authenticates the request. Who it authenticates as comes from the provider, which does this:
private com.park.utmstack.domain.User findFirstActiveAdmin() throws Exception {
List<com.park.utmstack.domain.User> users = userRepository.findAdminUsers();
...
return users.get(0);
}So the key means “act as the first active admin,” for any URL. NVD’s description lists the omissions: no path restriction, no constant-time comparison, no rate limiting, no audit logging. String.equals isn’t constant-time, and nothing recorded when the key was used, which matters later when you try to work out whether you were hit.
CVE-2026-82042 also depends on a precondition the advisory never explains. NVD says attackers who obtain the key value can authenticate, and the advisory doesn’t say how an attacker would get it. That’s why the 9.8 is best read as “what happens if the key leaks.”
UTMStack’s installer generates the key as a random 32-character secret. That’s a sound secret, but for CVE-2026-82042 the problem is that it’s a single long-lived value used everywhere. Searching the repository shows INTERNAL_KEY referenced by the agent manager, the installer, the backend’s gRPC interceptor, the SOC-AI service, the event-processor manager, the collector and module services, the compliance mailer and the PDF service. Every one of those either holds or sends the master key for the admin API.
The fix for CVE-2026-82042 keeps the key but narrows what it can do. In place of equals(), it uses a constant-time comparison and checks the request path against an allowlist:
} else if (StringUtils.hasText(apiKeyHeader) && MessageDigest.isEqual(
apiKeyHeader.getBytes(StandardCharsets.UTF_8),
envApiKey.getBytes(StandardCharsets.UTF_8))) {
String path = requestPath(request);
if (!INTERNAL_KEY_ALLOWED_PATHS.contains(path)) {
log.warn(ctx + ": Internal key presented for a non-internal path and ignored. ...");
} else if (!isSourceIpAllowed(request)) {
// rejected, source IP not in INTERNAL_KEY_ALLOWED_CIDRS
} else {
// authenticate, then:
log.info(ctx + ": Request authenticated via internal key. method={} path={} ip={}", ...);
}
}The allowlist has ten routes, the ones UTMStack’s own components call. Every accepted request is now audit-logged with method, path and caller IP, and an optional INTERNAL_KEY_ALLOWED_CIDRS setting can restrict where the key works from.
The CVE-2026-82042 fix narrows the key without making it harmless. Among the ten allowed routes are /api/elasticsearch/search, /api/utm-modules/module-details-decrypted, /api/utm-configuration-parameters and the federation token endpoints. That’s our reading of the list, not a claim from UTMStack: a leaked key can still read data and configuration after the fix.
Two more details in the patch. The source-IP restriction is off by default, which the commit’s own comments explain as avoiding breaking proxied deployments. And when it’s enabled, the code takes the leftmost X-Forwarded-For entry as the caller’s address, which a client can set unless your proxy overwrites that header.
The second flaw is shorter and arguably worse. UTMStack’s incident-response feature sends commands to agents through a websocket handler, which in v11.2.13 looked like this:
@MessageMapping("/command/{hostname}")
public void processCommand(@NotNull String command, @DestinationVariable @NotNull String hostname) {
String executedBy = SecurityUtils.getCurrentUserLogin()
.orElseThrow(() -> new InternalServerErrorException("Current user login not found"));
AgentDTO agentDTO = this.agentGrpcService.getAgentByHostname(hostname);
// ...
incidentResponseCommandService.sendCommand(String.valueOf(agentDTO.getId()), commandVar,
commandVM.getOriginType(), commandVM.getOriginId(), commandVM.getReason(),
executedBy, commandVM.getShell(), new StreamObserver<>() { /* ... */ });
}The only check is that the caller has a login name. Any authenticated user, whatever their role, could name a hostname and send a command to that agent. The advisory notes agent processes commonly run as root or SYSTEM, so a read-only analyst account becomes remote command execution across the monitored fleet.
The fix is six lines:
if (!SecurityUtils.isCurrentUserInRole(AuthoritiesConstants.ADMIN)) {
throw new AccessDeniedException(ctx + ": Incident response command execution requires admin privileges");
}To its credit, the handler already passed executedBy along with each command, so use by a named account was likely recorded, though we haven’t checked how it’s stored. The weakness was authorization, not logging.
This is where the advisories and the repository disagree about CVE-2026-82042. Both VulnCheck and NVD say “before 11.2.16.” We checked the repository directly:
| Version | Released | Contains the fix? |
|---|---|---|
| 11.2.13 | Aug 10 | No, vulnerable code confirmed in both files |
| 11.2.14 | Sep 25 | Yes, the fix commit is an ancestor and both files show the patched code |
| 11.2.15 | Sep 30 | Yes |
| 11.2.16 | Oct 1 | Yes |
| 12.0.0 | Sep 29 | Different code line; neither class exists in its tree |
The 11.2.14 release notes say it includes “patches for disclosed CVEs” and “reduced exposure of credentials and secrets,” so the fix wasn’t silent, it was just two releases earlier than the CVE records suggest. We can’t tell why the records say 11.2.16. Either way, 11.2.14 or later is patched, and upgrading to 11.2.16 is the safe default.
Version 12.0.0 doesn’t contain the two vulnerable classes, but we haven’t audited it for other issues, so treat that as “not these bugs,” not “safe.”
We read the current code while checking the CVE-2026-82042 fix. These aren’t CVEs, we haven’t tested either on a running instance, and we’re describing them to help you check your own deployment, not as confirmed vulnerabilities.
1. The PDF service logs the key. In v11.2.16, PdfService logs Requesting PDF creation to URL : {} at INFO level, and the URL it builds includes an accessKey query parameter. For scheduled compliance emails, the compliance mailer calls it with INTERNAL_KEY as that access key. If that path runs on your install, the master key may be sitting in your backend logs.
2. A global flag guards decrypted module secrets. The /utm-modules/module-details-decrypted route only returns data if InternalApiKeyFilter.isApiKeyHeaderInUse() is true. That flag is a static field shared across every request, so under concurrent load a request could in principle read a value set by another. Whether that’s exploitable depends on details we haven’t tested.
If you run UTMStack, the first is cheap to check yourself:
# Look for the master key leaking into backend logs (adjust the path to your deployment)
grep -r "accessKey=" /path/to/utmstack/backend/logs/ | headAnything that matches means rotating INTERNAL_KEY. We’d also suggest sharing both observations with UTMStack’s maintainers before relying on them publicly.
You’re exposed if both of these are true:
INTERNAL_KEY value could have leaked, or someone with low-level access could reach the key from an environment variable, a config file, a backup or a log.For CVE-2026-82041, condition two is simply “you have any authenticated user you wouldn’t trust with root on your endpoints,” which in most organizations is nearly everyone with a login.
INTERNAL_KEY after upgrading. Before the fix there was no audit logging, so you can’t prove the old key wasn’t used. We haven’t verified UTMStack’s rotation procedure, so follow its documentation.INTERNAL_KEY_ALLOWED_CIDRS to the networks your own containers use, and make sure any reverse proxy overwrites X-Forwarded-For.Pre-fix versions can’t tell you whether the key was used, but the patched filter writes two log lines that are worth watching after you upgrade:
# A key presented against a route it isn't allowed on: a strong sign the key is known to someone
grep "Internal key presented for a non-internal path and ignored" /path/to/backend/logs/*
# Every key-authenticated request, with method, path and caller IP
grep "Request authenticated via internal key" /path/to/backend/logs/*The first line is the important one. Your own components only call allowlisted routes, so a “non-internal path” warning means something else holds the key. For CVE-2026-82041, review incident-response command history for commands issued by accounts that aren’t administrators.
Two patterns here show up across products, and both are worth testing for.
A shared static secret is a master key. One value used by a dozen components means any one of them leaking it compromises all of them, and a flat secret can’t be scoped. We’d test where it lives, who can read it, and what it unlocks.
“Authenticated” is not “authorized.” CVE-2026-82041 checked that a user existed and never checked what role they held. Websocket and message-handler endpoints are easy to forget because they sit outside the REST controllers people review, and our AI VAPT services methodology tests them with low-privilege accounts specifically.
One hypothesis, untested: the new allowlist compares the raw request URI. We wrote about the same class of mismatch in Cisco’s SD-WAN bug, where a filter and a backend disagreed on what an encoded path meant. It would be worth testing whether UTMStack’s does too.
CVE-2026-82042 is an authentication bypass (CWE-306) in UTMStack. Before the fix, presenting a valid Utm-Internal-Key header authenticated a request as the first active admin on any endpoint, with no rate limiting or audit logging. NVD scores it 9.8, assuming the attacker has the key.
We found no evidence of exploitation. It isn’t in CISA’s Known Exploited Vulnerabilities catalog, and VulnCheck’s advisory makes no exploitation statement.
CVE-2026-82041 is a missing-authorization flaw (CWE-862) in UTMStack’s incident-response command websocket. Any authenticated user, regardless of role, could send operating-system commands to any connected agent. It’s NVD-scored 9.9 under CVSS 3.1 and 6.5 under CVSS 4.0.
11.2.14 and later fix CVE-2026-82042, based on the repository. The CVE records say “before 11.2.16,” but the fix commit is in the 11.2.14 release, which shipped September 25, 2026. Upgrading to 11.2.16 is the safe default.
To fix CVE-2026-82042, upgrade to 11.2.16 or at least 11.2.14, then rotate INTERNAL_KEY, set INTERNAL_KEY_ALLOWED_CIDRS, and watch for the new log line that flags the key being used on a non-internal path, which is the clearest sign of CVE-2026-82042 abuse after you upgrade.
The advisories don’t say. The key is a 32-character random secret shared across UTMStack’s components, so it could be exposed through environment variables, configuration, backups or logs. In v11.2.16 the PDF service logs a URL containing the key for compliance emails, which is worth checking on your own install.
CVE-2026-82042 wasn’t a clever exploit, it was a design choice: one shared secret that meant “admin, everywhere,” plus a command channel that never asked what role you held. Both are fixed, the fix is public, and the release notes weren’t silent about it.
Upgrade to 11.2.14 or later, rotate the internal key, and check your logs for the two things we flagged. The other lesson is for anyone building a platform like this: a key that works on every path is a master key, and the fix isn’t a better key, it’s a smaller door.
Categories
Related articles
