CVE-2026-57170: Server-Side Template Injection Bypass in Compliance-Trestle Include Tags

Compliance-trestle (Trestle) is a specialized Python SDK and command-line orchestration utility designed to automate the creation, validation, and maintenance of NIST Open Security Controls Assessment Language (OSCAL) formatted compliance documentation. Trestle acts as a compiler and authoring tool that bridges structured compliance models (JSON/YAML) with human-readable and trackable formats like Markdown. The tool is heavily utilized within automated DevSecOps pipelines and compliance-as-code infrastructures.\n\nThe attack surface exists primarily in the CLI authoring subsystem, specifically within commands like trestle author jinja and markdown generation procedures. This component parses markdown documentation templates containing customized template logic to assemble system security plans (SSPs) and profiles. Because compliance artifacts often integrate inputs from multiple stakeholders, external, untrusted OSCAL data can be parsed, compiled, and rendered by local automated runners.\n\nThis vulnerability, tracked as CVE-2026-57170 and GHSA-mr95-65j8-9mxp, is categorized under CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine) and CWE-94 (Improper Control of Generation of Code). It occurs because of an incomplete remediation of a previous Server-Side Template Injection (SSTI) flaw (CVE-2026-46439). While the initial fix restricted core template evaluation to a single pass, customized template compilation paths within the extension modules remained unmitigated.

The underlying flaw stems from the behavior of custom Jinja2 template extensions implemented in Compliance-trestle. The engine exposes custom extensions called mdsection_include and md_clean_include inside trestle/core/jinja/tags.py. These tags are meant to import clean Markdown sections into a master output template, dynamically processing layout structures during generation.\n\nTo achieve this, the extensions programmatically compile and parse the external content files back into template nodes using the raw Jinja2 compilation pipeline. During this parsing operation, the extensions pass the standard, non-sandboxed compiler environment (self.environment) to the child parser instance. As a result, any template tags ({{ ... }}) embedded inside the included file are evaluated inside the parent environment's security context.\n\nThis architectural design establishes a direct data-flow path from arbitrary content written to documentation files to the template compiler. When Trestle evaluates a template using these tags on a generated markdown file, it compiles any nested payload using the full, unmitigated Python Jinja2 environment. An attacker with control over the markdown content or the source compliance models can execute arbitrary Python methods via standard template exploitation chains.

Analysis of the vulnerable implementation in trestle/core/jinja/tags.py reveals how the host environment was shared directly with the local parser:\n\npython\n# Vulnerable implementation in tags.py\nlocal_parser = Parser(self.environment, content)\ntop_level_output = local_parser.parse()\nreturn top_level_output.body\n\n\nBecause self.environment is a standard jinja2.Environment, the parsing execution is entirely unmitigated. The patch resolves this by wrapping the environment initialization inside a SandboxedEnvironment class from the jinja2.sandbox module:\n\npython\n# Patched implementation in tags.py\nfrom jinja2.sandbox import SandboxedEnvironment\n\nparse_env = self.environment\nif not isinstance(self.environment, SandboxedEnvironment):\n parse_env = SandboxedEnvironment(\n loader=self.environment.loader,\n extensions=self.environment.extensions,\n trim_blocks=self.environment.trim_blocks,\n autoescape=self.environment.autoescape,\n )\n\nlocal_parser = Parser(parse_env, content)\ntop_level_output = local_parser.parse()\n\n\nIn addition to sandboxing the compiler environment, the developers introduced a robust input neutralization scheme in the writers (SSPMarkdownWriter and DocsControlWriter). This defensive layer interceptor uses the _neutralize_jinja_delimiters helper to map any instances of standard Jinja brackets {{ and }} into [[ and ]]. Because these rewritten delimiters are not recognized by the Jinja engine, they are printed as plaintext literals, neutralizing potential template injection vectors. The mitigation is highly effective, as it prevents arbitrary input from crossing the boundary into executable code paths.

Exploitation of CVE-2026-57170 is a multi-step process that requires the capability to insert custom string sequences into an OSCAL compliance source or local markdown document. An attacker first designs a python command execution payload utilizing standard python reflection techniques. A standard target pattern leverages available globals inside context objects like cycler to reference the underlying operating system interpreter:\n\njinja\n{{ cycler.__init__.__globals__.os.popen('whoami').read() }}\n\n\nOnce the payload is formulated, the attacker embeds it in an OSCAL structure, such as a component-definition description or an organization-level control narrative. The attacker then triggers a Trestle task that compiles the OSCAL files into markdown, such as generating an SSP. During this phase, the vulnerability is latent as the engine merely writes the string verbatim into an intermediate Markdown format.\n\nThe exploit triggers when an automated document compilation run processes a Jinja template that uses either of the insecure inclusion tags. When the compilation script evaluates {% md_clean_include \"vulnerable_description.md\" %}, the underlying parser processes the generated file. As the parser encounters the unneutralized template delimiters, it compiles and executes the payload, running the shell payload under the host operating system context.\n\nmermaid\ngraph LR\n A[\"OSCAL JSON Input (Attacker Controlled)\"] -->|\"trestle author/assemble\"| B[\"Generated Markdown (Verbatim Prose)\"]\n B -->|\"md_clean_include tag\"| C[\"Jinja2 Custom Extension (tags.py)\"]\n C -->|\"Non-Sandboxed Environment Parser\"| D[\"Arbitrary Python Code Execution (RCE)\"]\n

The security impact of CVE-2026-57170 is critical, as it enables arbitrary code execution within the execution environment of Compliance-trestle. When executed in automated DevSecOps pipelines, this allows an attacker to compromise CI/CD runners, hijack container environments, and steal sensitive environment variables, secrets, and deployment keys. If run locally by an administrator, the attacker obtains the privileges of the active local terminal session.\n\nThe vulnerability is scored with a CVSS v3.1 rating of 7.8 (High). The vector details are CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The Local (AV:L) designation reflects that exploitation requires the target runner to execute the script against a compromised source file. Since no complex configurations or permissions are needed beyond standard document updates, the complexity is low and the impact is total.\n\nWhile there is currently no evidence of exploitation in the wild, the low execution barrier and potential for compromising centralized compliance pipelines make it a critical concern. Secure supply chain configurations should prioritize isolating automated documentation-generation environments from highly sensitive pipeline secrets.

The primary path for remediation is upgrading the Compliance-trestle installation to a patched release. For environments using the 4.x release line, the dependency must be updated to version 4.1.0 or higher. Organizations leveraging the legacy 3.x branch must apply the backport release by updating to version 3.12.4.\n\nIf immediate dependency upgrades are not feasible, temporary mitigation strategies must be applied. The first defensive option is to implement strict repository review requirements. No raw OSCAL or markdown files should be processed by Trestle without mandatory pull request reviews validating that no template delimiters {{ or }} are present in prose text.\n\nAdditionally, automated workflows should run Trestle executions inside sandboxed container environments with minimal privileges. Ensure that network ingress and egress are restricted for the build container, and prevent the execution container from accessing master credential vaults or repository write tokens. This limits the exposure and blocks exfiltration steps of potential exploits.