CVE-2026-123372 · Package
NO FIX YET · SEE WHAT TO DO
compose-lint, a Docker Compose security linter, copies values from a sibling .env file into finding messages when an image field references them. In a CI workflow that writes secrets to that file and lints untrusted pull-request content, an attacker can make a secret's full value appear in job logs, JSON output, SARIF files and Code Scanning alerts.
first public Sep 28, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Exposure needs a workflow that writes real secrets into a .env file beside the Compose files and then lints content an outsider can change, such as pull_request_target jobs, same-repository branches, or a retained .env on a self-hosted runner. Fork pull requests usually have no secrets and so are not a path. Teams that run compose-lint only on trusted code with no secrets in the workspace can skip it.
Not affected if fork-prs-only, no-secrets-in-env-file, version-0.32.0-or-later
Who cares ci, compose-lint, docker-compose, github-actions
compose-lint --version or check the pinned version in your lockfile or workflow file; affected versions are 0.22.0 through 0.32.0..env file next to a Compose file and then runs compose-lint on pull-request content, including pull_request_target workflows..env file is left on a self-hosted runner where compose-lint runs.compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.22.0 until 0.32.0, compose-lint substitutes values from a sibling .env file into image fields and quotes the resolved value in CL-0004 and CL-0019 finding messages and fix text. In a workflow that writes secrets into that file and then lints untrusted pull-request content, an attacker can reference a secret variable so its whole value reaches the job log, JSON output, SARIF artifacts, and Code Scanning alerts. Fork pull requests normally lack secrets, so exploitation requires a secret-bearing workflow such as pull_request_target, same-repository branches, or a retained .env on a self-hosted runner, and the pass or fail result is unchanged. This issue is fixed in version 0.32.0.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
0.32.0This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.