NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦 GitHub Actions🐍 PyPI
Not in CISA KEV

compose-lint: Incomplete fix for GHSA-jf3h-8jvx-vcrg: a run stopped at the finding limit quotes a secret from a CI-generated `.env`GHSA-rm8w-w798-g545

Fix: tmatens/compose-lint#978

GHSA-rm8w-w798-g545 is a Information Exposure vulnerability in tmatens/compose-lint. A fix is available for tmatens/compose-lint — see the affected versions and patch details below.

Also known asCVE-2026-123796
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs23th percentile — riskier than 23% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

2 pkgs affected
📦tmatens/compose-lint🐍compose-lint

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects GitHub Actions, PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Impact

This is an incomplete fix for GHSA-jf3h-8jvx-vcrg. 0.32.0 made findings quote the ${NAME} a sibling .env filled in, instead of its value. The same release added a stop at 20,000 findings per document, and that stop is checked before the quoting step. A run that hits it reports the findings graded so far with the resolved values still in them, in text, JSON and SARIF output. That happens with or without --allow-partial-coverage.

The attack is the one GHSA-jf3h-8jvx-vcrg describes. In a CI workflow that writes secrets into the .env beside the Compose file, a pull request changes a line to image: "${DB_PASSWORD}". It also pushes the document past 20,000 findings, which a few hundred lines can do, because an aliased list is graded once for each service that uses it. The secret's value is quoted in a finding that reaches the job log, the 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 run exits 2, or 0 with --allow-partial-coverage, after the output has been written.

The preconditions are the same as for GHSA-jf3h-8jvx-vcrg. The workflow writes secrets into the .env beside the Compose file and runs on pull requests from authors who should not see them, such as a pull_request_target workflow that lints the pull request's files. Pull requests from forks normally run without secrets, so the common setup is not exposed. The inflated document is visible in the pull request, but the workflow runs before anyone reviews it.

Found during an internal pre-1.0 security review.

Python package. compose-lint 0.32.0. Earlier releases have no finding limit, and their quoting gap is GHSA-jf3h-8jvx-vcrg itself.

GitHub Action. Action tag v0.32.0 is affected. Tags before v0.22.0 install the newest release unless version: is set, so they currently install 0.32.0.

pre-commit hook. rev: v0.32.0.

Docker image. composelint/compose-lint:0.32.0, :0.32 and latest are affected when the .env is mounted with the project.

Patches

No fixed release yet.

Workarounds

  • Run with --no-env, which skips the sibling .env.
  • Don't write secrets into the .env beside the Compose file in a job that lints untrusted pull requests.

Reproduction

project/.env          DB_PASSWORD=example-secret      (written by CI, not committed)
project/compose.yml   x-p: &p [ ...200 port mappings... ]
                      services: one service with image: "${DB_PASSWORD}" and ports: *p,
                                plus about 100 more services with ports: *p

compose-lint --format sarif compose.yml exits 2 with "grading stopped at 20000 findings", and the reported findings contain example-secret. The same file with fewer services stays under the limit and quotes ${DB_PASSWORD}. Checked against the 0.32.0 wheel from PyPI, using a synthetic value.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦GitHub Actionstmatens/compose-lint≥ 0.32.0&&< 0.33.00.33.0
🐍PyPIcompose-lint≥ 0.32.0&&< 0.33.00.33.0pip install --upgrade 'compose-lint==0.33.0'

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for tmatens/compose-lint, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update tmatens/compose-lint to 0.33.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rm8w-w798-g545 is resolved across your whole dependency graph.

  3. Workarounds

    Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Frequently Asked Questions

### Impact This is an incomplete fix for GHSA-jf3h-8jvx-vcrg. 0.32.0 made findings quote the `${NAME}` a sibling `.env` filled in, instead of its value. The same release added a stop at 20,000 findings per document, and that stop is checked before the quoting step. A run that hits it reports the findings graded so far with the resolved values still in them, in text, JSON and SARIF output. That happens with or without `--allow-partial-coverage`. The attack is the one GHSA-jf3h-8jvx-vcrg describes. In a CI workflow that writes secrets into the `.env` beside the Compose file, a pull request cha
O3 Security · Impact-Aware SCA

Is GHSA-rm8w-w798-g545 in your dependencies?

Find it across GitHub Actions, PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
compose-lint: Incomplete fix for GHSA-jf3h-8jvx-vcrg: a…