CVE-2026-52776 in Compliance-trestle
Summary
by MITRE • 08/26/2026
Compliance-trestle (Trestle) is a tooling platform for managing compliance as code. In versions before 3.12.4 and versions 4.0.0 through 4.0.3, the URLSecurityValidator that guards trestle's remote-fetch paths against server-side request forgery can be bypassed to reach loopback, link-local, cloud-metadata, and internal network endpoints it was designed to block. The blocklist does not canonicalize IPv4-mapped IPv6 literals such as [::ffff:169.254.169.254], which resolve to IPv6Address objects that never match the blocked IPv4 ranges, and it does not block the unspecified address 0.0.0.0, which routes to local services on Linux and inside containers. An attacker who can supply or influence an OSCAL artifact that trestle fetches, such as a malicious profile whose imports reference one of these bypass URLs, can cause the HTTPSFetcher and SFTPFetcher paths to contact cloud instance-metadata services, loopback interfaces, or internal hosts. This issue is fixed in versions 3.12.4 and 4.1.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified within Compliance-trestle represents a critical server-side request forgery (SSRF) flaw stemming from insufficient input validation and canonicalization of network addresses during remote resource fetching operations. As a tooling platform designed to manage compliance as code, trestle relies on the ability to fetch external resources such as OSCAL artifacts, profiles, and benchmarks. To mitigate risks associated with SSRF attacks, the application employs a URLSecurityValidator intended to restrict access to internal or sensitive network endpoints including loopback interfaces, link-local addresses, cloud metadata services, and other private ranges. However, in versions prior to 3.12.4 and within the range of 4.0.0 through 4.0.3, this security control is fundamentally flawed due to a lack of proper address normalization before comparison against blocked lists. This architectural oversight allows an attacker who can influence or supply OSCAL artifacts containing malicious import references to bypass these restrictions entirely.
The technical root cause lies in the handling of IPv6-mapped IPv4 literals and unspecified addresses by the underlying validation logic. Specifically, the blocklist fails to canonicalize IPv4-mapped IPv6 representations such as [::ffff:192.0.2.1] or similar constructs targeting sensitive ranges like 169.254.169.254, which is commonly used for cloud instance metadata services in environments like AWS and Azure. Because the validator processes these literals without converting them into a consistent format that matches the blocked IPv4 ranges, they resolve to IPv6Address objects that do not trigger the existing deny rules. Consequently, requests directed at these addresses are permitted through the security filter. Furthermore, the validation logic neglects to block the unspecified address 0.0.0.0. On Linux systems and within containerized environments, connecting to this address typically routes traffic to local services bound on all interfaces, effectively granting access to internal applications that should remain isolated from external or semi-trusted inputs.
The operational impact of this vulnerability is severe for organizations relying on trestle for automated compliance assessments. An attacker with the ability to inject malicious OSCAL content can force the HTTPSFetcher and SFTPFetcher components to initiate connections to arbitrary internal destinations. This capability enables several dangerous outcomes, including exfiltration of sensitive data from cloud metadata endpoints which often contain authentication credentials or configuration details, scanning of internal network services for further exploitation opportunities, and potential interaction with local administrative interfaces that may lack additional authentication controls. Since the vulnerability affects both HTTP-based fetchers and SFTP paths, it provides a versatile vector for lateral movement within compromised environments where trestle is deployed as part of an automated compliance pipeline.
This flaw aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically illustrating how improper validation of user-supplied URLs can lead to unauthorized access to internal resources. It also relates to CWE-20 Improper Input Validation, where the application fails to sanitize or normalize input data before processing it against security policies. From an offensive security perspective, this vulnerability maps to MITRE ATT&CK technique T1598 Phishing for Intranet Credentials if used in conjunction with social engineering to deliver malicious OSCAL files, and potentially T1046 Network Service Discovery if leveraged to map internal network topology through error responses or timing differences. The lack of canonicalization is a common pitfall in security controls that rely on string matching rather than semantic understanding of the data being processed.
To mitigate this vulnerability, organizations must immediately upgrade Compliance-trestle to version 3.12.4 or later, where these validation gaps have been addressed by implementing robust address normalization and comprehensive blocking rules for both IPv4 and IPv6 representations. Until an upgrade is feasible, defensive measures should include placing trestle behind a reverse proxy that enforces strict egress filtering based on IP reputation and range, ensuring that the application cannot reach internal subnets or cloud metadata endpoints directly. Additionally, input validation at the ingestion point of OSCAL artifacts can be strengthened by pre-processing URLs to resolve all IPv4-mapped IPv6 literals into their standard IPv4 equivalents before passing them to the validator. Monitoring network egress traffic for connections to known sensitive ranges such as 169.254.0.0/16 and 0.0.0.0 can also aid in detecting exploitation attempts in real time, providing an additional layer of defense-in-depth against SSRF attacks targeting compliance tooling platforms.