Description

compliance-trestle is a tooling platform for managing compliance as code. Prior to versions 3.12.2 and 4.0.3, the HTTPSFetcher._do_fetch() method passes a user-supplied URL directly to requests.get() without validation. This allows an attacker to perform Server-Side Request Forgery, targeting internal services or cloud metadata endpoints. Versions 3.12.2 and 4.0.3 fix the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.7",
  "pubDate": "2026-08-14T17:18:14.710Z",
  "pubdate": "2026-08-14T17:18:14.710Z",
  "executiveSummary": "An unauthenticated Server-Side Request Forgery (SSRF) vulnerability exists in the compliance-trestle tooling platform. The flaw resides within the HTTPSFetcher._do_fetch() method, which fails to properly validate user-supplied URLs prior to passing them into the underlying requests.get() function.\nThis architectural oversight enables malicious actors to coerce the application into initiating arbitrary HTTP requests on behalf of the server. Consequently, attackers can leverage this capability to target internal network services, restricted administrative interfaces, and cloud provider metadata endpoints.\nThe implications of successful exploitation include potential exposure of sensitive internal infrastructure, data exfiltration, and unauthorized access to cloud instance metadata service credentials. Systems utilizing affected versions of compliance-trestle are at risk if exposed to untrusted input sources.\nThe vulnerability affects compliance-trestle versions prior to 3.12.2 and 4.0.3. Mitigation requires upgrading the software to version 3.12.2, version 4.0.3, or later, where proper URL validation checks have been implemented to neutralize the attack vector.",
  "technicalDetails": "The root cause of the vulnerability stems from insufficient input validation and sanitization within the URL fetching logic of compliance-trestle. Specifically, the HTTPSFetcher._do_fetch() method accepts a user-supplied URL parameter and directly passes it to the requests.get() method without enforcing strict scheme, host, or IP address filtering.\nThe vulnerable component is the HTTPSFetcher class and its associated _do_fetch() method, which handles remote resource retrieval across affected versions prior to 3.12.2 and 4.0.3.\nThe attack flow proceeds as follows: An attacker supplies a crafted URL designed to target internal network resources or sensitive cloud metadata endpoints (such as 169.254.169.254 in cloud environments). When the compliance-trestle application processes this input, the HTTPSFetcher._do_fetch() method executes a call to requests.get() using the malicious URL.\nBecause the application executes the outbound request directly from the host operating system's network stack, it bypasses standard perimeter network controls. The server acts as a proxy, fetching the requested internal resource and potentially returning error messages, data payloads, or side-effect outcomes back to the attacker, depending on how the application handles the HTTP response.\nAuthentication and privilege requirements depend on the entry point exposing the URL parameter to user control, but the underlying flaw itself requires no privileged access to the fetching component once malicious input is supplied. The network exposure is dictated by whether the application processes untrusted input over network interfaces.\nPost-exploitation impact includes unauthorized interaction with internal microservices, reconnaissance of internal network topologies, and retrieval of cloud instance metadata tokens which may grant further access to cloud infrastructure resources."
}