CVE-2026-57170

Reporter: Cavan Loughran, Celvex Group Inc.

Summary

The fix for CVE-2026-46439 (3.12.2 / 4.0.3) removed the recursive re-render loop in trestle/core/commands/author/jinja.py render_template, but the custom include tags in trestle/core/jinja/tags.py (MDSectionInclude, MDCleanInclude) still re-parse the CONTENT of an included markdown file as a Jinja2 template via Parser(self.environment, ).parse() in a plain (non-sandboxed) jinja2.Environment. Because the trestle markdown writers (ssp_io.py SSPMarkdownWriter, docs_control_writer.py DocsControlWriter) write OSCAL prose / component-description fields verbatim (the {{ -> [[ neutralization is applied to parameter tables only), attacker-controlled OSCAL data that flows into an included markdown file is interpreted as template code and can achieve arbitrary code execution on the runner. This is the same trust boundary and impact as CVE-2026-46439 via a sink the fix did not cover.

Affected versions

4.0.3 and earlier on this code path (the include tags predate and were untouched by the parent fix); the 3.12.x line likewise. Verified present in the fixed release 4.0.3 by direct source read.

Technical detail

Sink (UNCHANGED by the parent fix), trestle/core/jinja/tags.py:

MDSectionInclude.parse (the {% mdsection_include 'file.md' '# Section' %} tag), approximately: md_content, _, _ = self.environment.loader.get_source(self.environment, markdown_source.value) # ~line 90 ... local_parser = Parser(self.environment, md_section.content.raw_text) # ~line 104 <-- RE-PARSE top_level_output = local_parser.parse() # ~line 105 return top_level_output.body # ~line 106

MDCleanInclude.parse (the {% md_clean_include 'file.md' %} tag), approximately: md_content, _, _ = self.environment.loader.get_source(self.environment, markdown_source.value) # ~line 141 ... local_parser = Parser(self.environment, content) # ~line 150 <-- RE-PARSE top_level_output = local_parser.parse() # ~line 151 return top_level_output.body # ~line 152

Parser(self.environment, ).parse() compiles the included file's markdown text AS A JINJA TEMPLATE and splices the resulting AST .body directly into the host template's compilation. Any {{ ... }} / {% ... %} present in the included file is interpreted as template code, not emitted as literal text. The single-pass fix in render_template has no effect on this: the re-parse happens at compile time inside the tag, on a string the outer render loop never sees as data.

Environment is NOT sandboxed (UNCHANGED by the fix), trestle/core/commands/author/jinja.py _create_jinja_environment: return Environment(loader=FileSystemLoader(template_folder), extensions=extensions(), trim_blocks=True, autoescape=True) This is a plain jinja2.Environment, not jinja2.sandbox.SandboxedEnvironment, so a re-parsed expression has full access to the usual Jinja SSTI gadget chain leading to OS command execution. autoescape=True HTML-escapes output but does not constrain expression evaluation, so it does not mitigate code execution.

Data bridge (partial neutralization only): the included markdown is, in trestle's documented workflow, produced from OSCAL by the trestle generators / writers. trestle/core/ssp_io.py SSPMarkdownWriter writes control statement prose (get_control_statement_ssp) and component implementation descriptions (prose = by_comp.description) into markdown with no Jinja-delimiter escaping. trestle/core/docs_control_writer.py DocsControlWriter writes control section prose (self._md_file.new_line(prose)) and part text raw. The maintainers DO know about the {{-in-data risk: ssp_io.py applies line.replace('{{', '[[').replace('}}', ']]') to neutralize delimiters, but ONLY inside the parameter-table method (_parameter_table). Control-statement prose and component description fields receive no such neutralization. So an OSCAL field such as an SSP component description, a control statement override, or a catalog part prose string that contains {{ }} lands verbatim in the generated markdown, and then the include tag re-parses and executes it.

Why this is a genuine incomplete fix (not the same bug): the parent CVE-2026-46439 re-evaluation site was the recursive loop in render_template (main template output) in commands/author/jinja.py, which the fix removed. THIS variant's re-evaluation site is Parser(self.environment, ...) inside mdsection_include / md_clean_include (included file content) in core/jinja/tags.py, which the fix did NOT touch, and which runs in a plain (non-sandboxed) Environment. Same class (SSTI -> RCE), same trust boundary (untrusted OSCAL data), different and still-live sink.

Reachability (non-destructive reasoning)

1. A pipeline ingests OSCAL content (component-definition, SSP, profile, or catalog) that an external or lower-trust party can influence (a component supplier, a control-narrative contributor, an upstream catalog). This is precisely the parent's accepted attacker: a malicious actor supplies crafted OSCAL content in an automated pipeline (CI/CD).
2. The pipeline runs trestle author ssp-generate (or equivalent) which writes the OSCAL prose/description fields into markdown verbatim. A field value such as {{ cycler.init.globals['os'].popen('id').read() }} survives intact (no neutralization on prose/description).
3. The pipeline then runs trestle author jinja -i template.md.j2 ... where the template composes the document with {% md_clean_include 'generated_control.md' %} or {% mdsection_include 'generated_ssp.md' '# Some Section' %} (the documented populate-content-from-other-documents pattern).
4. The include tag re-parses the generated markdown in the non-sandboxed environment and the embedded expression executes => code runs with the privileges of the trestle process (the CI runner).

Non-destructive confirmation: place a benign marker such as {{ 77 }} in an OSCAL prose / description field; run the generator that writes it to markdown; include that markdown with {% md_clean_include 'generated.md' %}; observe 49 rather than the literal {{ 77 }}, confirming evaluation. A malicious field would use the standard Jinja gadget chain; that is deliberately NOT included here.

Impact

Arbitrary code execution on the trestle process (the CI runner), under the same trust boundary that CVE-2026-46439 was assigned on (untrusted OSCAL data in an automated pipeline). Non-sandboxed environment => full RCE in a release that is patched for the parent CVE.

Remediation

(a) render the include re-parse through jinja2.sandbox.SandboxedEnvironment, OR (b) emit the included file content as literal text (do not re-parse it as a template), OR (c) extend the {{ / }} -> [[ / ]] neutralization in ssp_io.py / docs_control_writer.py to ALL OSCAL prose / description / part-text writes, not just parameter tables. Option (a) or (b) is the durable fix; (c) is defense-in-depth.