How severe is CVE-2026-123372?

No CVSS score has been assigned to CVE-2026-123372 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-123372?

CVE-2026-123372 affects the following packages: tmatens/compose-lint (GitHub Actions), compose-lint (PyPI). Ecosystems affected: GitHub Actions, PyPI.

How do I fix CVE-2026-123372?

Update tmatens/compose-lint to 0.32.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-123372 is resolved across your whole dependency graph.

How do I detect CVE-2026-123372 in my GitHub Actions, PyPI dependencies?

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.

How do I mitigate CVE-2026-123372 if there is no patch (or I can't update yet)?

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.

Is CVE-2026-123372 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-123372 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-123372?

CVE-2026-123372 has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 32th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-123372?

CVE-2026-123372 is classified as Information Exposure (CWE-200), CWE-532 (CWE-532). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-123372 published, and has it been updated?

CVE-2026-123372 was published on November 9, 2026 and was last updated on November 11, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 GitHub Actions🐍 PyPI

Not in CISA KEV

CVE-2026-123372 — compose-lint

Fix: tmatens/compose-lint@977da97

CVE-2026-123372 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.

compose-lint: A pull request can make compose-lint quote a secret from a CI-generated `.env` into its findings

Also known asGHSA-jf3h-8jvx-vcrg

Published

Nov 9, 2026

Updated

Nov 11, 2026

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.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs32th percentile — riskier than 32% 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

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 and SARIF. A value shorter than 8 characters is shown as written, because short values are also words the guidance itself uses; docs/what-a-run-reads.md states this limit.

Workarounds

Upgrade to 0.32.0 or later.
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   services: {web: {image: "${DB_PASSWORD}"}}

compose-lint --format sarif compose.yml reports CL-0004 with the message Image 'example-secret' has no tag, ....

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
📦GitHub Actions	`tmatens/compose-lint`	≥ 0.22.0&&< 0.32.0	0.32.0
🐍PyPI	`compose-lint`	≥ 0.22.0&&< 0.32.0	0.32.0`pip install --upgrade 'compose-lint==0.32.0'`

Detection & mitigation playbook

Open-source dependency

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.
Fix
Update tmatens/compose-lint to 0.32.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-123372 is resolved across your whole dependency graph.
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 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.