Description

Server-side request forgery (SSRF) in the /har/test endpoint in QD 20220208 through 20250803. Fetcher.build_request() in libs/fetcher.py constructs an httpclient.HTTPRequest from user-supplied JSON without validating URL scheme, host, or IP range. The /har/test handler does not require authentication, enabling unauthenticated remote attackers to force the QD server to send arbitrary HTTP requests to internal network resources and cloud metadata endpoints. validate_cert is set to False, disabling TLS verification.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-31T16:18:34.220Z",
  "pubdate": "2026-08-31T16:18:34.220Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in the /har/test endpoint of the QD product, affecting versions 20220208 through 20250803.\nThe vulnerability originates from the Fetcher.build_request() function within libs/fetcher.py, which fails to enforce validation on user-supplied URLs during the construction of httpclient.HTTPRequest objects.\nAn unauthenticated remote attacker can leverage this flaw to force the QD server to perform arbitrary outbound HTTP requests.\nThis allows adversaries to bypass network perimeters, facilitating unauthorized access to internal resources, private services, and cloud metadata endpoints (e.g., IMDS).\nBecause the implementation explicitly sets validate_cert to False, the application is also susceptible to Man-in-the-Middle (MitM) attacks during these forged requests.\nThe lack of authentication requirements for the /har/test endpoint significantly lowers the barrier for exploitation, making it a critical security risk for any network-exposed deployment.",
  "technicalDetails": "The vulnerability resides in the interaction between the /har/test API endpoint and the backend request processing logic found in libs/fetcher.py. The application accepts JSON input from users, which is subsequently parsed and passed directly into the Fetcher.build_request() function.\nThe root cause is a failure to implement proper input sanitization or allow-listing for the user-supplied URL structure. The code does not perform verification of the URL scheme, hostname, or destination IP address, enabling attackers to target sensitive internal infrastructure that would otherwise be inaccessible from the public internet.\nThe exploitation flow initiates with an unauthenticated attacker sending a crafted HTTP request to the /har/test endpoint. By manipulating the JSON payload, the attacker influences the httpclient.HTTPRequest construction. Since the application fails to restrict the destination to external domains, an attacker can specify internal IP addresses (e.g., 127.0.0.1, 169.254.169.254) or internal service hostnames.\nOnce the request is initiated, the server executes the forged request on behalf of the attacker. Because validate_cert is explicitly configured to False, the server ignores TLS certificate validation, which not only facilitates SSRF but also prevents the detection of intercepted or malicious responses if the server interacts with infrastructure that uses custom or self-signed certificates.\nIn cloud environments, this flaw is particularly critical as it allows for the exfiltration of sensitive information from cloud provider metadata services. These services often rely on the source IP of the request to grant access to credentials, identity tokens, and configuration details. An attacker can craft a request to these endpoints, receive the response, and potentially use the retrieved credentials to escalate privileges within the cloud environment.\nFurthermore, the SSRF can be utilized as a gateway for internal port scanning and service discovery. By observing the time-based responses or error messages returned by the /har/test endpoint, an attacker can map the internal network, identify running services, and attempt to exploit non-public interfaces that rely on the assumption of network-level security.\nThe impact is magnified by the fact that no administrative or user-level authentication is required, meaning any entity with network access to the /har/test endpoint can interact with the internal backend services of the QD server."
}