compose-lint: Workflow command injection through SARIF-directory errors triggered by pull request symlinks 

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 published as part of GHSA-r7j4-crjv-h467, together with four other gaps in the same fix. Each gap now has its own advisory.

Patches

Fixed in 0.32.0. The SARIF-directory error names the sarif-file: input as written.

Workarounds

• Upgrade to 0.32.0 or later.
• Keep sarif-file at the workspace root, for example sarif-file: results.sarif.

Reproduction

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 a committed symlink to a directory named d\n::warning::X that contains a regular file reports, creates an annotation. With sarif-file at the repository root it creates none.