<?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://db.gcve.eu</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>Wed, 11 Nov 2026 16:18:28 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-125125</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-125125</link>
      <description>&lt;p&gt;compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From version 0.30.0 until 0.32.0, the compose-lint GitHub Action prints the resolved directory from a failed sarif-file subdirectory creation without effective command suppression. Version 0.30.0 has no stop-commands window, while version 0.31.0 prints this error outside its stop-commands window. A pull request can place a committed symlink on that path to a directory whose name contains a newline followed by a workflow command, causing the SARIF-directory error to issue commands in the job log. Only the Action with sarif-file pointing into a subdirectory is affected; a workspace-root SARIF file, the compose-lint package, the pre-commit hook, and the Docker image do not expose this message. This issue is fixed in version 0.32.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From version 0.30.0 until 0.32.0, the compose-lint GitHub Action prints the resolved directory from a failed sarif-file subdirectory creation without effective command suppression. Version 0.30.0 has no stop-commands window, while version 0.31.0 prints this error outside its stop-commands window. A pull request can place a committed symlink on that path to a directory whose name contains a newline followed by a workflow command, causing the SARIF-directory error to issue commands in the job log. Only the Action with sarif-file pointing into a subdirectory is affected; a workspace-root SARIF file, the compose-lint package, the pre-commit hook, and the Docker image do not expose this message. This issue is fixed in version 0.32.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-125125</guid>
    </item>
    <item>
      <title>GHSA-xcf7-88g6-7xr8 — compose-lint: Workflow command injection through SARIF-directory errors triggered by pull request symlinks</title>
      <link>https://db.gcve.eu/vuln/ghsa-xcf7-88g6-7xr8</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; GitHub Actions: tmatens/compose-lint&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;In Action tags v0.30.0 and v0.31.0, when `sarif-file:` names a file in a subdirectory that can&amp;#39;t be created, the Action prints the directory&amp;#39;s resolved path in an error message. In v0.31.0 that message is outside the window in which the Action turns command processing off, and v0.30.0 has no such window. A pull request can commit a symlink on that path to a directory whose name contains a newline followed by a command.&lt;/p&gt;
&lt;p&gt;A pull request can therefore create annotations, fold or hide parts of the job log, or issue other commands the runner accepts, when CI runs compose-lint over it, before anyone reviews it. The pass/fail result is not changed.&lt;/p&gt;
&lt;p&gt;Only the Action is affected, and only when `sarif-file:` points into a subdirectory. The documented setup, `sarif-file: results.sarif` at the repository root, is not affected. The `compose-lint` package, the pre-commit hook and the Docker image do not print this message.&lt;/p&gt;
&lt;p&gt;Found during an internal pre-1.0 security review. It was first published as part of GHSA-r7j4-crjv-h467, together with four other gaps in the same fix. Each gap now has its own advisory.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in 0.32.0. The SARIF-directory error names the `sarif-file:` input as written.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;- Upgrade to 0.32.0 or later.
- Keep `sarif-file` at the workspace root, for example `sarif-file: results.sarif`.&lt;/p&gt;
&lt;p&gt;### Reproduction&lt;/p&gt;
&lt;p&gt;On a GitHub-hosted runner (runner 2.337.0), the Action at v0.31.0 with `sarif-file: out/reports/results.sarif`, where `out` is…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; GitHub Actions: tmatens/compose-lint&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;In Action tags v0.30.0 and v0.31.0, when `sarif-file:` names a file in a subdirectory that can&amp;#39;t be created, the Action prints the directory&amp;#39;s resolved path in an error message. In v0.31.0 that message is outside the window in which the Action turns command processing off, and v0.30.0 has no such window. A pull request can commit a symlink on that path to a directory whose name contains a newline followed by a command.&lt;/p&gt;
&lt;p&gt;A pull request can therefore create annotations, fold or hide parts of the job log, or issue other commands the runner accepts, when CI runs compose-lint over it, before anyone reviews it. The pass/fail result is not changed.&lt;/p&gt;
&lt;p&gt;Only the Action is affected, and only when `sarif-file:` points into a subdirectory. The documented setup, `sarif-file: results.sarif` at the repository root, is not affected. The `compose-lint` package, the pre-commit hook and the Docker image do not print this message.&lt;/p&gt;
&lt;p&gt;Found during an internal pre-1.0 security review. It was first published as part of GHSA-r7j4-crjv-h467, together with four other gaps in the same fix. Each gap now has its own advisory.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in 0.32.0. The SARIF-directory error names the `sarif-file:` input as written.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;- Upgrade to 0.32.0 or later.
- Keep `sarif-file` at the workspace root, for example `sarif-file: results.sarif`.&lt;/p&gt;
&lt;p&gt;### Reproduction&lt;/p&gt;
&lt;p&gt;On a GitHub-hosted runner (runner 2.337.0), the Action at v0.31.0 with `sarif-file: out/reports/results.sarif`, where `out` is…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-xcf7-88g6-7xr8</guid>
    </item>
  </channel>
</rss>
