GHSA-6wcv-rj3c-mhv3: compose-lint: .env read through a symlink outside the project can expose the CI job's environment
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 envfile:, 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 in uploaded JSON or SARIF artifacts or in Code Scanning alert text.
An include: entry's projectdirectory: has the same gap from 0.28.0: a directory symlink named there makes compose-lint read .env from wherever the link points.
Pull requests from forks normally run without secrets, and GitHub masks registered secrets in the job log, so in the common setup what can be read is runner metadata and whatever unmasked values the job's environment holds. That is why this is scored as low confidentiality impact. The impact is high in a job that runs untrusted pull requests with secrets in its environment, such as a pullrequesttarget workflow, or on a CI system that does not mask secrets, and also wherever the JSON or SARIF output is uploaded. The pass/fail result is not affected.
Found during an internal pre-1.0 security review.
Patches
Fixed in 0.31.0. Every .env read now applies the same containment check as envfile:. A .env that resolves outside the project is treated as missing and reported as an unread input. A projectdirectory: that resolves outside the project is refused, and that entry's files resolve against their own directories. A .env line containing a NUL byte is skipped.
Workarounds
- Run with --no-env, which skips the sibling .env entirely. - Don't run compose-lint on untrusted pull requests in a job whose environment holds secrets.
Reproduction
project/.env -> /proc/self/environ (symlink) project/compose.yml: services: web: image: "${FIRSTVARNAME}"
compose-lint check compose.yml --format json quotes the environment in the CL-0004 message ("Image '...' has no tag").
Other sources
compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.22.0 until 0.31.0, compose-lint follows a sibling .env symbolic link outside the project without applying its normal containment check. From 0.28.0, the same gap also affects an include projectdirectory link outside the project. A pull request can reference a variable from the linked file, causing substitution to place runner file or process-environment data into finding messages written to logs, JSON, SARIF artifacts, and Code Scanning alerts. Reading /proc/self/environ can expose the remainder of the linter process environment because NUL-separated entries are treated as one value, although disclosure requires a workflow that processes untrusted changes with useful environment data and GitHub normally withholds secrets from fork pull requests. The pass or fail result is not changed. This issue is fixed in version 0.31.0.
— OSV
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
actions/tmatens/compose-lintto a version that resolves this vulnerability.Fixed in 0.31.0 - Upgrade
Upgrade
pip/compose-lintto a version that resolves this vulnerability.Fixed in 0.31.0 - Upgrade
Upgrade
compose-lintto a version that resolves this vulnerability.Fixed in 0.31.0 - Configuration
Run compose-lint with --no-env to skip reading the sibling .env file.
compose-lint --no-env = enabled - Compensating control
Do not run compose-lint on untrusted pull requests in a job whose environment holds secrets.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
CI workflows that run compose-lint on untrusted pull-request changes are exposed when the workflow has useful runner file or process-environment data available. GitHub normally withholds secrets from fork pull requests, which reduces exposure in that common scenario.
What does an attacker need to do to exploit it?
An attacker needs to submit a change that causes compose-lint to follow a sibling .env symlink outside the project, or, from version 0.28.0, an include project_directory link outside the project. They must reference a variable from the linked file so its contents are substituted into finding output.
Where could disclosed data appear?
Disclosed values can be written into finding messages in logs, JSON output, SARIF artifacts, and Code Scanning alerts. A link to /proc/self/environ can expose the linter process environment because its NUL-separated entries are handled as one value.
What should teams do if they cannot immediately upgrade?
Avoid running affected versions on untrusted changes when the job has sensitive environment values or access to sensitive runner files. Review and restrict pull-request-controlled .env symlinks and, in versions 0.28.0 through 0.30.0, include project_directory links that point outside the project.
Does exploitation change the lint result?
No. The pass or fail result is not changed; the impact is disclosure through generated finding output.