Utmstack
Monthly
Authenticated JPQL injection in UTMStack SIEM deployments before 11.2.16 lets any holder of a low-privilege account read arbitrary database entities through the GET /api/utm-network-scans/searchPropertyValues endpoint, including sensitive credential tables such as jhi_user. The flaw is reachable by remote attackers (CVSS:4.0 AV:N/PR:L, assessed equivalently as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:N), so exploitation is confined to malicious insiders or attackers who have already obtained a valid credential - no unauthenticated internet path or non-default configuration is required beyond an authenticated session. No public exploit code has been identified and no confirmed active exploitation (CISA KEV) has been recorded at time of analysis; the primary risk is direct confidentiality loss, not data integrity or availability, and vendor-released patch 11.2.16 is available.
UTMStack deployments running versions before 11.2.16 can be fully taken over through an authentication bypass in the InternalApiKeyFilter, which accepts the shared Utm-Internal-Key header as proof of identity on every API endpoint rather than only on internal machine-to-machine routes. Tracked as CVE-2026-82042 (CWE-306, missing authentication for a critical function) and rated 9.3 under CVSS 4.0 with an equivalent CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, a single request that presents the correct key value grants full administrative API access without a user account, JWT, or user interaction, allowing the attacker to create accounts, manage users, exfiltrate data, and modify security rules. The decisive limiting factor is obtaining the secret itself: the key is a shared machine-to-machine credential held by sibling components such as agent-manager, the event-processor plugins, and the installer/updater, so realistic attack paths involve a leaked, default, or weak INTERNAL_KEY value, read access to the deployment environment, or compromise of a container that legitimately holds it. No public exploit code was identified at time of analysis and the flaw is not listed in CISA KEV, but the vendor-released fix in 11.2.16 hardens the filter with a fixed route allowlist, constant-time comparison, audit logging, and an optional INTERNAL_KEY_ALLOWED_CIDRS source-IP restriction.
Authenticated SQL injection in UTMStack before 11.2.16 lets any valid low-privilege logged-in user execute arbitrary SQL against the backend PostgreSQL database via the assetType and groupName parameters of GET /api/utm-asset-groups/searchGroupsByFilter. Because the database connection runs with DBA (PostgreSQL superuser-class) privileges, successful exploitation extends from full read and modification of stored data to potential filesystem access on the host. The vendor has released a fix in v11.2.16; no public exploit code has been identified at time of analysis, and the main practical constraint is that an authenticated session is required. Reported by VulnCheck, and tracked as CWE-89.
Server-side request forgery in UTMStack before 11.2.16 lets any authenticated user (even a low-privilege one) coerce the web-pdf microservice into fetching an arbitrary URL by supplying an unvalidated url parameter to GET /api/generate-pdf-report, with the fetched response rendered back into the returned PDF. A successful attack exposes internal-only resources the container can reach - backend APIs, the OpenSearch cluster, or a cloud instance-metadata endpoint (169.254.169.254) - making credential theft the highest-impact outcome on cloud-hosted deployments; there is no code execution, no data modification, and exploitation requires a valid UTMStack session (CVSS vector PR:L, so authentication is required). No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (not in CISA KEV); the CVE carries a CVSS 4.0 score of 6.3, while our independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) rates it High, with real-world impact gated by the server's network reachability to the targeted internal resource and, for the metadata path, by the instance running in a cloud environment.
Account enumeration in UTMStack before 11.2.16 lets unauthenticated remote attackers submit arbitrary email addresses to POST /api/account/reset-password/init and learn which ones are registered, because known accounts return HTTP 200 while unknown accounts return HTTP 500 with backend error details. The exposure is limited to confirming account existence - no credentials, session data, or code execution are obtained - making this a medium-severity information-disclosure issue (CWE-204) consistent with the independent assessment vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, which requires only that the web interface and the reset endpoint be network-reachable on a default deployment. No public exploit code and no confirmed active exploitation were identified at time of analysis; VulnCheck reported the issue and a vendor-released fix is available as v11.2.16, with the practical risk being follow-on targeted phishing or credential attacks that leverage a confirmed mailbox list.
Missing authorization in UTMStack before 11.2.16 allows any authenticated user, regardless of role, to execute arbitrary operating-system commands on connected agents via the /command/{hostname} STOMP destination, with agent processes commonly running as root or SYSTEM. Exploitation requires a valid UTMStack account (no elevated privilege needed) and at least one connected agent; there is no pre-authentication exposure, and no public exploit has been identified at time of analysis. Vendor-released patch: 11.2.16.
Server-side request forgery (SSRF) in UTMStack before 11.2.16 is a genuine but moderate-severity issue rather than a top-tier emergency: an authenticated user who can reach the POST/PUT /api/identity-providers endpoint can supply a crafted metadata URL that IdentityProviderService.validateMetadataUrl() accepts without validating target host, IP, or scheme, causing the server to issue attacker-directed requests to internal or cloud metadata hosts. The practical consequence is internal network reconnaissance and port scanning, plus exposure of cloud instance-metadata services such as 169.254.169.254 when UTMStack is deployed in a cloud environment; impact is otherwise confined to confidentiality (scope-changed C:L/I:N/A:N) and is gated by the requirement for a valid UTMStack account (PR:L). No public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the vendor has released version 11.2.16 as the fixed version.
Authenticated JPQL injection in UTMStack SIEM deployments before 11.2.16 lets any holder of a low-privilege account read arbitrary database entities through the GET /api/utm-network-scans/searchPropertyValues endpoint, including sensitive credential tables such as jhi_user. The flaw is reachable by remote attackers (CVSS:4.0 AV:N/PR:L, assessed equivalently as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:N), so exploitation is confined to malicious insiders or attackers who have already obtained a valid credential - no unauthenticated internet path or non-default configuration is required beyond an authenticated session. No public exploit code has been identified and no confirmed active exploitation (CISA KEV) has been recorded at time of analysis; the primary risk is direct confidentiality loss, not data integrity or availability, and vendor-released patch 11.2.16 is available.
UTMStack deployments running versions before 11.2.16 can be fully taken over through an authentication bypass in the InternalApiKeyFilter, which accepts the shared Utm-Internal-Key header as proof of identity on every API endpoint rather than only on internal machine-to-machine routes. Tracked as CVE-2026-82042 (CWE-306, missing authentication for a critical function) and rated 9.3 under CVSS 4.0 with an equivalent CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, a single request that presents the correct key value grants full administrative API access without a user account, JWT, or user interaction, allowing the attacker to create accounts, manage users, exfiltrate data, and modify security rules. The decisive limiting factor is obtaining the secret itself: the key is a shared machine-to-machine credential held by sibling components such as agent-manager, the event-processor plugins, and the installer/updater, so realistic attack paths involve a leaked, default, or weak INTERNAL_KEY value, read access to the deployment environment, or compromise of a container that legitimately holds it. No public exploit code was identified at time of analysis and the flaw is not listed in CISA KEV, but the vendor-released fix in 11.2.16 hardens the filter with a fixed route allowlist, constant-time comparison, audit logging, and an optional INTERNAL_KEY_ALLOWED_CIDRS source-IP restriction.
Authenticated SQL injection in UTMStack before 11.2.16 lets any valid low-privilege logged-in user execute arbitrary SQL against the backend PostgreSQL database via the assetType and groupName parameters of GET /api/utm-asset-groups/searchGroupsByFilter. Because the database connection runs with DBA (PostgreSQL superuser-class) privileges, successful exploitation extends from full read and modification of stored data to potential filesystem access on the host. The vendor has released a fix in v11.2.16; no public exploit code has been identified at time of analysis, and the main practical constraint is that an authenticated session is required. Reported by VulnCheck, and tracked as CWE-89.
Server-side request forgery in UTMStack before 11.2.16 lets any authenticated user (even a low-privilege one) coerce the web-pdf microservice into fetching an arbitrary URL by supplying an unvalidated url parameter to GET /api/generate-pdf-report, with the fetched response rendered back into the returned PDF. A successful attack exposes internal-only resources the container can reach - backend APIs, the OpenSearch cluster, or a cloud instance-metadata endpoint (169.254.169.254) - making credential theft the highest-impact outcome on cloud-hosted deployments; there is no code execution, no data modification, and exploitation requires a valid UTMStack session (CVSS vector PR:L, so authentication is required). No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (not in CISA KEV); the CVE carries a CVSS 4.0 score of 6.3, while our independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) rates it High, with real-world impact gated by the server's network reachability to the targeted internal resource and, for the metadata path, by the instance running in a cloud environment.
Account enumeration in UTMStack before 11.2.16 lets unauthenticated remote attackers submit arbitrary email addresses to POST /api/account/reset-password/init and learn which ones are registered, because known accounts return HTTP 200 while unknown accounts return HTTP 500 with backend error details. The exposure is limited to confirming account existence - no credentials, session data, or code execution are obtained - making this a medium-severity information-disclosure issue (CWE-204) consistent with the independent assessment vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, which requires only that the web interface and the reset endpoint be network-reachable on a default deployment. No public exploit code and no confirmed active exploitation were identified at time of analysis; VulnCheck reported the issue and a vendor-released fix is available as v11.2.16, with the practical risk being follow-on targeted phishing or credential attacks that leverage a confirmed mailbox list.
Missing authorization in UTMStack before 11.2.16 allows any authenticated user, regardless of role, to execute arbitrary operating-system commands on connected agents via the /command/{hostname} STOMP destination, with agent processes commonly running as root or SYSTEM. Exploitation requires a valid UTMStack account (no elevated privilege needed) and at least one connected agent; there is no pre-authentication exposure, and no public exploit has been identified at time of analysis. Vendor-released patch: 11.2.16.
Server-side request forgery (SSRF) in UTMStack before 11.2.16 is a genuine but moderate-severity issue rather than a top-tier emergency: an authenticated user who can reach the POST/PUT /api/identity-providers endpoint can supply a crafted metadata URL that IdentityProviderService.validateMetadataUrl() accepts without validating target host, IP, or scheme, causing the server to issue attacker-directed requests to internal or cloud metadata hosts. The practical consequence is internal network reconnaissance and port scanning, plus exposure of cloud instance-metadata services such as 169.254.169.254 when UTMStack is deployed in a cloud environment; impact is otherwise confined to confidentiality (scope-changed C:L/I:N/A:N) and is gated by the requirement for a valid UTMStack account (PR:L). No public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the vendor has released version 11.2.16 as the fixed version.