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
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact 0.31.0 fixed GHSA-6f4g-xm8v-pgv6, where text from a Compose file became GitHub Actions workflow commands in compose-lint's output. The fix escapes the command openers in compose-lint's own output, but not in the argument parser's error messages. When a repository path reaches compose-lint's arguments without a `--` before it, the argument parser prints it raw in its error message. That includes a carriage return, which the runner treats as a line break, so a command can also start a new line there. 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. Affected setups pass repository paths to compose-lint without a `--` before them: the pre-commit hook when `args:` is set without the documented trailing `--`, or the `compose-lint` package or Docker image called that way in a workflow. The pre-commit…
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 0.31.0 fixed GHSA-6f4g-xm8v-pgv6, where text from a Compose file became GitHub Actions workflow commands in compose-lint's output. `--format json` and `--format sarif` output never passed through that fix, so `##` inside a service name or other value reaches the log intact when the output is printed to stdout rather than written to a file. The runner acts on `##[` in the middle of a line, so the JSON layout does not prevent it. 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. Affected setups print JSON or SARIF output to a CI log from the `compose-lint` package, the pre-commit hook or the Docker image. Writing that output to a file, which SARIF upload requires, is not affected. The GitHub Action turns command processing off around each compose-lint run, so it is not affected. Found during an…
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 0.31.0 fixed GHSA-6f4g-xm8v-pgv6, where text from a Compose file became GitHub Actions workflow commands in compose-lint's output. The fix escapes the command openers in everything compose-lint prints, and the 0.31.0 changelog says the report "escapes both openers (also covering Azure Pipelines)". Five paths were left open: - Unicode whitespace before a line-leading `::`. The runner strips all Unicode whitespace from the start of a line before it looks for a command. compose-lint only accounted for spaces and tabs, so a no-break space or another Unicode space ahead of `::` is not escaped. It can come from a Compose value, or from a file name: the text report's file heading and per-file summary, and the `fix` summary on stderr, start with the path as given, so a directory named with a leading no-break space followed by `::` puts a command at the start of a line. This reaches those lines, the text report's fix guidance, the `fix` dry-run diff, and continuation lines of…
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 `compose-lint fix --apply` converts the line numbers its fixers work with into positions in the file. The YAML parser treats a lone carriage return, U+0085, U+2028 and U+2029 as line breaks, but the conversion counted only `\n`. One of those characters inside a quoted value, which most editors and diff views don't show, shifted every later edit down by one line. A Compose file from a pull request can use this to make a fix delete the line after the one it meant to change. For example, fixing CL-0014 (`logging: driver: none`) instead removes `driver: none` and the following `networks: [internal]`, moving the service off an internal-only network onto the default bridge. The result is still valid Compose, every check `fix` runs after editing passes, and the command reports `applied 1 fix(es)` and exits 0. A later `compose-lint check` passes too, because no rule requires `networks:`. The dry-run diff (without `--apply`) does show the removed lines, but `--apply` prints only…
Recommended action: Upgrade to 0.18.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.