compose-lint: Text in a pull request can still issue CI workflow commands through compose-lint 0.31.0's output

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 are those that print compose-lint's output to a CI log without the GitHub Action: the compose-lint package run directly in a workflow, the pre-commit hook run in CI, and the Docker image. The pre-commit hook is affected in its default configuration: it passes each changed file's path to compose-lint, and a path whose directory name starts with Unicode whitespace and :: reaches the report's file heading. The JSON/SARIF and command-line paths also need output left on stdout, or args: without the documented trailing --, which is why they alone would score lower. The GitHub Action turns command processing off around each compose-lint run, so of these paths only its own error message affects it, and only when sarif-file: points into a subdirectory. That setup is outside the documented one, which is why that path alone would also score lower.

Found during an internal pre-1.0 security review.

Docker image. composelint/compose-lint tag 0.31.0, the matching minor tag, and latest are affected.

Releases before 0.31.0 are covered by GHSA-6f4g-xm8v-pgv6, except the Action's error message, which also affects Action 0.30.0.

Patches

Fixed in 0.32.0. The line-start escaping covers every character the runner strips before ::, so it holds for quoted values and file names alike. JSON and SARIF on stdout escape ##[ inside strings as \u005b, which decodes to the same data. argparse's own messages go through the same sanitizer. ##vso[ is escaped everywhere. In the Action, the SARIF-directory error names the sarif-file: input as written.

Workarounds

• Upgrade to 0.32.0 or later.
• On GitHub Actions, use the tmatens/compose-lint Action, or bracket the compose-lint step with ::stop-commands::<random token> and ::<token>::, as the Action does.
• In the Action, keep sarif-file at the workspace root, for example sarif-file: results.sarif.
• Write --format json and --format sarif output to a file rather than the log.
• End the pre-commit hook's args: with --. This closes the command-line path only; it does not stop a file name at the start of a report line, so in CI also bracket the pre-commit step with ::stop-commands:: as above.
• On Azure Pipelines, don't print compose-lint's output from runs over untrusted pull requests to the job log.

Reproduction

On compose-lint 0.31.0 on a GitHub-hosted runner (runner 2.337.0), each of the following creates an annotation:

• a Compose file with image: "nginx\n\u00a0::notice::X", linted with the text report;
• a directory named \u00a0::notice::X (a no-break space, then ::notice::X) holding a compose.yml, linted with compose-lint -- '<that directory>/compose.yml', or by the pre-commit hook in its default configuration;
• a service named a##[warning]X, linted with --format json or --format sarif to stdout;
• compose-lint '--##[warning]X/compose.yml' with no --;
• the Action with sarif-file: out/reports/results.sarif, where out is a committed symlink to a directory named d\n::warning::X that contains a regular file reports.

The same inputs with a plain space in place of the no-break space, or with -- before the path, or with sarif-file at the repository root, create none. The same inputs on compose-lint 0.30.0 create annotations even with a plain space, which is GHSA-6f4g-xm8v-pgv6. The composelint/compose-lint:0.31.0 image produces byte-identical output to the package.