GHSA-88f4-frh5-gmcr: compose-lint: A `.compose-lint.yml` symlinked outside the project is read, and a parse error quotes part of the target
compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.2.0 until 0.32.0, compose-lint automatically follows a .compose-lint.yml policy-file symbolic link outside the project and includes part of the target line when that external file fails YAML parsing. A pull request can point the policy file at a runner credential file, causing about 30 characters around an attacker-uncontrolled parse position to appear in standard error, JSON errors, and SARIF tool execution notifications uploaded by the GitHub Action. The run exits with an error and the attacker cannot select the exact disclosed line, but public logs or Code Scanning output can reveal part of the target. This issue is fixed in version 0.32.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
compose-lintto a version that resolves this vulnerability.Fixed in 0.32.0
Event History
Frequently Asked Questions
Which environments are realistically exposed to this issue?
The risk applies where compose-lint processes a repository-controlled .compose-lint.yml symlink and the runner can read files outside the project directory. Exposure is especially relevant for GitHub Action runs whose logs or Code Scanning SARIF results may be visible to untrusted users or publicly accessible.
What must an attacker be able to do to trigger disclosure?
An attacker needs to get a pull request processed with a .compose-lint.yml policy-file symlink pointing to a readable external file, such as a runner credential file. The external target must fail YAML parsing for compose-lint to emit a portion of the target line.
Is exploitation a full-file disclosure?
No. The parse error exposes roughly 30 characters around a parse position, and the attacker cannot choose the exact line disclosed. The lint run exits with an error, but the excerpt can still appear in standard error, JSON errors, and uploaded SARIF tool-execution notifications.
What should teams do if they cannot immediately update?
Avoid running compose-lint on untrusted pull requests where repository content can supply a .compose-lint.yml symlink to files outside the project. Also restrict visibility of workflow logs and Code Scanning output that could contain parse-error excerpts.
How can teams determine whether they are affected?
Check whether compose-lint versions from 0.2.0 through before 0.32.0 are used, particularly in GitHub Actions. Review repositories and pull requests for .compose-lint.yml symbolic links and inspect prior compose-lint parse failures in logs, JSON output, and SARIF results.