UTMStack EUVD-2026-91801

Requires a valid authenticated session (PR:L) with access to the GET /api/utm-network-scans/searchPropertyValues endpoint; any low-privilege account that can reach this network-scan endpoint is sufficient - no admin role, user interaction, or non-default configuration is described as necessary. The concrete prerequisite is the ability to supply the 'value' request parameter, which is passed through String.format() into a JPQL string and executed via em.createQuery() without parameter binding, making the endpoint injectable by default in versions before 11.2.16. The primary limiting factor is authentication: an unauthenticated internet attacker cannot reach it directly, so realistic risk is scoped to malicious insiders or attackers who have already obtained any valid credential.

This is a genuine but moderate-priority issue rather than a drop-everything emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) scores 7.1 (High) and is internally consistent with the description: network-reachable, low complexity, but requiring authentication (PR:L) and yielding confidentiality-only impact (VC:H, VI:N, VA:N). No EPSS score, no CISA KEV listing, and no public exploit (POC) are present in the input, so there is no signal of active or widespread exploitation - exploitation status is 'no public exploit identified at time of analysis.' An SSVC-style read would be: exploitation=none observed, automatable=yes (the injection is a simple query-string manipulation that could be scripted), technical impact=partial-to-total for confidentiality since credential tables (jhi_user) are reachable. The dominant risk driver is the sensitivity of the data exposed (password hashes/credentials), not probability of mass exploitation. The key limiting factor - authentication (PR:L) - meaningfully reduces exposure versus an unauthenticated flaw, but note that in a SIEM/XDR product any authenticated user dumping the user/credential table is a serious privilege-escalation stepping stone. Data gap to flag: the source-code evidence supplied (InternalApiKeyFilter changes) corresponds to a sibling fix (CVE-2026-82042), not the JPQL injection, so the exact remediation commit for THIS CVE is not independently confirmed from the provided material.

A low-privileged but authenticated UTMStack user (or an attacker who has phished/obtained any valid account) sends a crafted GET request to /api/utm-network-scans/searchPropertyValues with a malicious value parameter that is concatenated via String.format() into a JPQL query and executed without parameter binding. By injecting JPQL that references other entities, the attacker reads arbitrary data including the jhi_user credential table, harvesting usernames and password hashes. No public exploit code is identified in the provided data, but the technique is straightforward given the described root cause.