UTMStack EUVD-2026-91799

Attacker must hold a valid authenticated UTMStack session (CVSS PR:L - even a low-privilege account suffices; not an anonymous/default-config flaw). Exploitation is performed by supplying an attacker-controlled, unvalidated url parameter to GET /api/generate-pdf-report, which the web-pdf microservice fetches server-side. Realistic impact additionally requires that the server have network reachability to the targeted internal resource - the OpenSearch cluster, internal backend endpoints, or, for the highest-impact credential-theft path, a cloud instance-metadata service (169.254.169.254), which only applies to cloud-hosted deployments. Limiting factors: authentication is required, no code execution or data modification results (read/confidentiality-oriented SSRF only), and metadata-credential theft depends on the instance running in a cloud environment with metadata accessible.

This is a genuine but mid-tier risk best treated as a targeted/standard-priority patch rather than an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation, but PR:L means it is NOT unauthenticated - an attacker needs a valid UTMStack account, which meaningfully limits mass exploitation. The 6.3 (Medium) score is driven by SC:H (high confidentiality impact on subsequent/internal systems) while VC/VI/VA are all N, which is consistent with a classic SSRF: the vulnerable app itself is not directly damaged, but it is weaponized to reach internal services (OpenSearch, backend endpoints) and, critically, the cloud instance-metadata service - a path to credential theft. No EPSS score, no CISA KEV listing, and no public exploit/POC flag were provided, so there is no evidence of active or widespread exploitation; the finding comes from a VulnCheck advisory with a vendor patch. Key signals are therefore consistent (Medium CVSS, authenticated, no exploitation evidence) rather than conflicting. Caveat: the patch commit supplied in the input (4e7a727, InternalApiKeyFilter) explicitly references a DIFFERENT CVE (CVE-2026-82042) and does not contain the SSRF url-validation fix, so the exact code remediation for this specific CVE could not be verified from the provided evidence - verify the fix against vendor release v11.2.16.

A low-privileged but authenticated UTMStack user sends a crafted GET /api/generate-pdf-report request with the url parameter pointing at the cloud instance-metadata endpoint (e.g. 169.254.169.254) or an internal OpenSearch URL. The web-pdf microservice fetches that internal resource and renders the response into the returned PDF, leaking cloud credentials or internal data back to the attacker. No public exploit code was identified, though VulnCheck published an advisory describing the flaw.