Description

Compliance-trestle (Trestle) is a Python SDK and command-line tool for managing OSCAL compliance documents. In versions prior to 3.12.4 and 4.0.0 through 4.0.3, the custom Jinja2 include tags mdsection_include and md_clean_include re-parse the content of an included Markdown file as Jinja2 template code in a non-sandboxed environment, allowing server-side template injection that can lead to arbitrary code execution. The MDSectionInclude and MDCleanInclude tags in Trestle/core/jinja/tags.py pass included file content to Parser(self.environment, ...).parse(), splicing it into the host template's compilation, and the environment is a plain jinja2.Environment rather than a SandboxedEnvironment, so any expressions in the file are evaluated with full access to the usual SSTI gadget chain. Because Trestle's Markdown writers emit OSCAL prose and component-description fields verbatim, applying delimiter neutralization only to parameter tables, attacker-controlled OSCAL data such as a control statement, part prose, or component description containing Jinja2 syntax flows into an included Markdown file and is executed when the include tag re-parses it. This issue is fixed in version 4.1.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T05:18:11.763Z",
  "pubdate": "2026-08-26T05:18:11.763Z",
  "executiveSummary": "Compliance-trestle is susceptible to a Server-Side Template Injection (SSTI) vulnerability stemming from the insecure handling of Jinja2 templates. Versions prior to 3.12.4 and 4.0.0 through 4.0.3 are impacted.\nThe vulnerability allows an attacker to achieve arbitrary code execution on the host system. This is triggered when malicious Jinja2 syntax, injected into OSCAL data fields (such as control statements or component descriptions), is processed by the mdsection_include or md_clean_include tags.\nBecause the underlying Jinja2 environment is not sandboxed, the application parses and executes embedded expressions within included Markdown files. An attacker with the ability to influence OSCAL content can escalate this into full remote code execution.\nThis presents a high-severity risk, as it bypasses intended input sanitization boundaries. Successful exploitation requires the application to process maliciously crafted OSCAL content through the vulnerable include tags, potentially compromising the integrity and confidentiality of the host environment.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of custom Jinja2 include tags, specifically mdsection_include and md_clean_include, located within Trestle/core/jinja/tags.py. These tags are designed to incorporate external Markdown file content into a parent Jinja2 template; however, they perform an unsafe operation by passing the raw content of the included file directly to the environment.parse() method.\nThe Jinja2 environment utilized by these tags is initialized as a standard jinja2.Environment rather than a security-hardened jinja2.SandboxedEnvironment. By invoking the parser on the contents of the included file without environment restrictions, the application treats the file's data as executable template code rather than static content. This architectural flaw permits the evaluation of any Jinja2 expressions found within the included files, providing an entry point for an SSTI gadget chain.\nThe attack flow originates from the application's Markdown writers, which fail to perform sufficient delimiter neutralization on OSCAL prose, control statements, or component description fields. When an attacker provides a payload containing Jinja2 syntax within these OSCAL fields, the malicious string is written to an intermediary Markdown file. When Trestle subsequently triggers the include tag for that file, the internal parser re-evaluates the file content, executing the injected Jinja2 logic in the context of the host process.\nThe lack of a sandbox environment allows an attacker to access sensitive objects and functions available within the Jinja2 context, facilitating arbitrary code execution. Because the system performs this re-parsing automatically, an attacker does not necessarily require direct shell access, but rather the ability to manipulate the OSCAL data structures processed by the Trestle SDK. Post-exploitation impact includes full system compromise, data exfiltration, and lateral movement within the environment hosting the compliance documents. The vulnerability is definitively resolved in version 4.1.0, which presumably implements stricter parsing controls or migrates to a secure, sandboxed execution environment for user-influenced Markdown inclusions."
}