Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact In Action tags v0.30.0 and v0.31.0, when `sarif-file:` names a file in a subdirectory that can't be created, the Action prints the directory'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. 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. 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. Found during an internal pre-1.0 security review. It was first…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This is an incomplete fix for GHSA-jf3h-8jvx-vcrg. 0.32.0 made findings quote the `${NAME}` a sibling `.env` filled in, instead of its value. The same release added a stop at 20,000 findings per document, and that stop is checked before the quoting step. A run that hits it reports the findings graded so far with the resolved values still in them, in text, JSON and SARIF output. That happens with or without `--allow-partial-coverage`. The attack is the one GHSA-jf3h-8jvx-vcrg describes. In a CI workflow that writes secrets into the `.env` beside the Compose file, a pull request changes a line to `image: "${DB_PASSWORD}"`. It also pushes the document past 20,000 findings, which a few hundred lines can do, because an aliased list is graded once for each service that uses it. The secret's value is quoted in a finding that reaches the job log, the JSON output and the SARIF uploaded to Code Scanning. GitHub masks registered secrets in the job log, but not in uploaded JSON or…
Recommended action: Upgrade to 0.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Like Docker Compose, compose-lint follows symlinks when it reads a project's files. Unlike Compose, compose-lint up to 0.24.0 could then put the contents of a file from *outside* the project into its output, where the author of a pull request can read it. A pull request can commit a symlink, under a name compose-lint reads, pointing at a file on the CI runner: - The Compose file itself (0.2.0–0.24.0). A `compose.yml` that is a symlink, whether the pre-commit hook passes its name or the Action or a bare run finds it. - `compose.override.yml` (0.22.0–0.24.0), which compose-lint merges automatically. - A `COMPOSE_FILE` entry (0.22.0–0.24.0) in a `.env` beside the Compose file. When the target is not valid YAML, the parse error quotes the line it failed on. Docker Compose, given the same file, reports only a line number. That line reaches standard error (the job log), JSON `errors[]`, and the SARIF `toolExecutionNotifications`, which the Action uploads to Code…
Recommended action: Upgrade to 0.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact compose-lint automatically reads a `.compose-lint.yml` policy file beside the Compose file. It is meant to read nothing outside the project directory, but it follows that file if it is a symlink, wherever it points. A pull request can commit `.compose-lint.yml` as a symlink to a file on the CI runner. If the target is not valid YAML, the error compose-lint reports quotes part of the line the parser failed on. That quote reaches the job log (standard error), JSON `errors[]`, and the SARIF `toolExecutionNotifications`, which the Action uploads to Code Scanning. The run exits 2. What can be read is small. The quote is cut to about 30 characters around the error position, and the attacker cannot choose which line of the target the parser fails on. For an INI-style credentials file, this was the start of the second line (`aws_access_key_id = ` followed by the first characters of the value). Targets in `KEY=value` form, and YAML files that parse, disclosed no values in testing.…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. 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. 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.…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The GitHub Actions runner treats certain text in a step's output as commands. The legacy form, `##[command]`, is recognized anywhere in a line. compose-lint's text report prints service names, environment keys and lines of the Compose file, and it does not neutralize `##[`. Inside the compose-lint Action, a Compose file from a pull request can therefore: - create fake error or warning annotations on the pull request (`##[error]`, `##[warning]`) - fold the rest of the log, including the real verdict, out of sight (`##[group]`) - blank out chosen strings for the rest of the log (`##[add-mask]`) GitHub has postponed removing the deprecated `set-output` log command, so the runner still honors it. A test run of the Action on a GitHub-hosted runner confirmed that a `::set-output` line from a Compose file is processed. Whether it can override the Action's own `sarif-written` output, which decides whether the SARIF upload step runs, has not been tested. The exit code and the…
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact compose-lint fills in `${VAR}` references from the `.env` file next to the Compose file. It is meant to read nothing outside the project directory, and `env_file:`, `include:` and `extends:` paths are checked for that. The `.env` read is not. If `.env` is a symlink, compose-lint follows it wherever it points. A pull request can add a `.env` symlink to any file on the CI runner and a Compose file that references a variable from it. compose-lint substitutes the value and quotes it in finding messages, which go to the log and to JSON and SARIF output. The worst target is `/proc/self/environ`, the linter's own environment. The Compose file only needs to reference the name of the first variable in it: because that file separates variables with NUL bytes rather than newlines, the substituted value is the entire rest of the environment. On a CI runner that environment holds whatever the workflow put there, including secrets. GitHub masks registered secrets in the job log, but not…
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.