CVE-2026-123372

### Impact Since 0.22.0, compose-lint fills in `${VAR}` references from the `.env` beside the Compose file, as Compose does. The documentation says values under `environment:` are never resolved from a `.env`, "that is where secrets live". But `image:` values are resolved, and CL-0004 and CL-0019 quote the resolved image in their message and fix text. Some CI workflows write secrets into that `.env` before linting or building. In such a workflow, a pull request that changes one line to `image: "${DB_PASSWORD}"`, or `image: "nginx:${DB_PASSWORD}"`, gets the secret's value quoted in a finding. The finding reaches the job log, JSON output, and the SARIF uploaded to Code Scanning. GitHub masks registered secrets in the job log, but not in uploaded JSON or SARIF artifacts or in Code Scanning alert text. The pass/fail result is not affected. This needs a workflow that writes secrets into the `.env` beside the Compose file *and* runs on pull requests from authors who should not see them. Pull requests from forks normally run without secrets, so the common setup is not exposed, which is why this is scored as low confidentiality impact. Where the conditions hold, such as a `pull_request_target` workflow, pull requests from branches in the same repository, or a self-hosted runner that keeps a populated `.env` in the checkout, the whole value is disclosed. Found during an internal pre-1.0 security review. **GitHub Action.** Action tags v0.22.0 through v0.31.0 install their own compose-lint version and are affected. Earlier tags install the newest release unless `version:` is set, and so currently install an affected one. **Docker image.** `composelint/compose-lint` tags 0.22.0 through 0.31.0, the matching minor tags, and `latest` are affected when the `.env` is mounted with the project. ### Patches Fixed in 0.32.0. Rules still grade the value the sibling `.env` substituted, but findings, fix guidance and notes quote the `${NAME}` reference in its place, in text, JSON a