<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 10:10:16 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-57170 — Trestle SSTI in Jinja2 include tags allows arbitrary code execution (Incomplete fix of CVE-2026-46439)</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-57170</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; oscal-compass compliance-trestle&lt;/p&gt;
&lt;p&gt;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&amp;#39;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&amp;#39;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; oscal-compass compliance-trestle&lt;/p&gt;
&lt;p&gt;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&amp;#39;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&amp;#39;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-57170</guid>
    </item>
    <item>
      <title>PYSEC-2026-4029 — Trestle SSTI in Jinja2 include tags allows arbitrary code execution (Incomplete fix of CVE-2026-46439)</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-4029</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: compliance-trestle&lt;/p&gt;
&lt;p&gt;Reporter: Cavan Loughran, Celvex Group Inc.&lt;/p&gt;
&lt;p&gt;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, &amp;lt;file text&amp;gt;).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 {{ -&amp;gt; [[ 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Technical detail
----------------
Sink (UNCHANGED by the parent fix), trestle/core/jinja/tags.py:&lt;/p&gt;
&lt;p&gt;MDSectionInclude.parse (the {% mdsection_include &amp;#39;file.md&amp;#39; &amp;#39;# Section&amp;#39; %} tag), approximately:
  md_content, _, _ = self.environment.loader.get_source(self.environment, markdown_source.value)   # ~line 90
  ...…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: compliance-trestle&lt;/p&gt;
&lt;p&gt;Reporter: Cavan Loughran, Celvex Group Inc.&lt;/p&gt;
&lt;p&gt;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, &amp;lt;file text&amp;gt;).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 {{ -&amp;gt; [[ 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Technical detail
----------------
Sink (UNCHANGED by the parent fix), trestle/core/jinja/tags.py:&lt;/p&gt;
&lt;p&gt;MDSectionInclude.parse (the {% mdsection_include &amp;#39;file.md&amp;#39; &amp;#39;# Section&amp;#39; %} tag), approximately:
  md_content, _, _ = self.environment.loader.get_source(self.environment, markdown_source.value)   # ~line 90
  ...…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-4029</guid>
    </item>
  </channel>
</rss>
