<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-11T14:55:30.726326+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-123372</id>
    <title>fkie_cve-2026-123372</title>
    <updated>2026-11-11T14:55:30.728039+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.22.0 until 0.32.0, compose-lint substitutes values from a sibling .env file into image fields and quotes the resolved value in CL-0004 and CL-0019 finding messages and fix text. In a workflow that writes secrets into that file and then lints untrusted pull-request content, an attacker can reference a secret variable so its whole value reaches the job log, JSON output, SARIF artifacts, and Code Scanning alerts. Fork pull requests normally lack secrets, so exploitation requires a secret-bearing workflow such as pull_request_target, same-repository branches, or a retained .env on a self-hosted runner, and the pass or fail result is unchanged. This issue is fixed in version 0.32.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-123372"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-jf3h-8jvx-vcrg</id>
    <title>GHSA-jf3h-8jvx-vcrg — compose-lint: A pull request can make compose-lint quote a secret from a CI-generated `.env` into its findings</title>
    <updated>2026-11-11T14:55:30.728104+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: compose-lint, GitHub Actions: tmatens/compose-lint</p>
<p>### Impact</p>
<p>Since 0.22.0, compose-lint fills in `${VAR}` references from the `.env` beside the Compose file, as Compose does. The documentation says values under `environment:` are never resolved from a `.env`, "that is where secrets live". But `image:` values are resolved, and CL-0004 and CL-0019 quote the resolved image in their message and fix text.</p>
<p>Some CI workflows write secrets into that `.env` before linting or building. In such a workflow, a pull request that changes one line to `image: "${DB_PASSWORD}"`, or `image: "nginx:${DB_PASSWORD}"`, gets the secret's value quoted in a finding. The finding reaches the job log, JSON output, and the SARIF uploaded to Code Scanning. GitHub masks registered secrets in the job log, but not in uploaded JSON or SARIF artifacts or in Code Scanning alert text. The pass/fail result is not affected.</p>
<p>This needs a workflow that writes secrets into the `.env` beside the Compose file *and* runs on pull requests from authors who should not see them. Pull requests from forks normally run without secrets, so the common setup is not exposed, which is why this is scored as low confidentiality impact. Where the conditions hold, such as a `pull_request_target` workflow, pull requests from branches in the same repository, or a self-hosted runner that keeps a populated `.env` in the checkout, the whole value is disclosed.</p>
<p>Found during an internal pre-1.0 security review.</p>
<p>**GitHub Action.** Action tags v0.22.0 through v0.31.0 install their own com…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-jf3h-8jvx-vcrg"/>
  </entry>
</feed>
