CVE-2026-125125

### 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.