Summary
UTMStack contains a server-side request forgery vulnerability in its PDF report generation service. An authenticated attacker may supply a crafted URL to make the server request internal services, potentially exposing sensitive data through the generated PDF.
Affected context
The vulnerability affects UTMStack deployments where the PDF report endpoint is reachable by authenticated users and the supplied URL is passed to the web-pdf microservice without sufficient validation. Risk is higher when the service can reach internal backend endpoints, OpenSearch, or cloud instance-metadata services from its network position.
Exploit preconditions
- Attack surface: The authenticated
GET /api/generate-pdf-reportendpoint - Required access: A valid authenticated account able to request PDF reports
- Trigger point: The
urlparameter processed byPdfService.downloadPdf() - Why exploitation is possible: The server makes outbound requests based on attacker-controlled URL input without adequately restricting destinations, protocols, or network ranges
Why this happens
The underlying flaw is server-side request forgery, mapped to CWE-918. The application treats a user-controlled URL as a trusted fetch target and performs the request from a privileged server-side network position. Without robust destination validation, attackers may redirect requests toward internal services that are not directly exposed to them.
Potential impact
- An attacker may retrieve sensitive content from internal backend endpoints
- OpenSearch data or administrative interfaces could be exposed
- Cloud instance-metadata responses could disclose credentials or deployment information
- Internal network topology and service details could be revealed
- Sensitive responses may be rendered into downloadable PDF reports
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied URLs and constraining server-side network access.
Common defensive patterns include:
- Allowing requests only to an explicit, tightly controlled destination allowlist
- Restricting supported schemes, ports, redirects, and resolved IP addresses
- Blocking loopback, link-local, private, reserved, and metadata-service address ranges
- Revalidating destinations after DNS resolution and across redirects
- Separating report-fetching services from sensitive internal networks
- Applying least-privilege identity and network policies to the web-pdf microservice
- Avoiding the inclusion of fetched content unless its origin and content type are verified
How teams detect issues like this
High-level detection can combine application review, runtime monitoring, and policy enforcement:
- Use static analysis to identify HTTP clients receiving URL values from request parameters
- Review code paths involving PDF generation, URL fetching, redirect handling, and DNS resolution
- Monitor outbound requests from report-generation services to private, loopback, link-local, and metadata addresses
- Enforce egress network policies that limit service-to-service and external destinations
- Alert on unusual report-generation requests, repeated URL changes, or responses containing internal service markers
- Use automated security review tools to flag SSRF-prone data flows for manual validation
