CVE-2026-123796 in compose-lint
Summary
by MITRE • 11/09/2026
compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.32.0 until 0.33.0, compose-lint's incomplete remediation for .env secret disclosure checks the 20,000-finding limit before replacing resolved values with their variable references. A pull request can combine a secret-referencing image field with aliased content that produces more than 20,000 findings, causing the early-stop path to emit already graded findings with the resolved secret value in text, JSON, SARIF, and Code Scanning output. Exploitation requires a workflow that writes secrets into the sibling .env and lints untrusted changes, and the run exits 2 unless --allow-partial-coverage is used. This issue is fixed in version 0.33.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/09/2026
The vulnerability identified within compose-lint versions ranging from 0.32.0 to 0.33.0 represents a critical information disclosure flaw rooted in the tool's internal logic for handling secret remediation and output generation. As a Docker Compose security linter, compose-lint is designed to identify dangerous misconfigurations before deployment, specifically focusing on detecting secrets that may be inadvertently exposed through environment variables or configuration files. The core technical flaw lies in the sequence of operations performed when resolving variable references versus enforcing finding limits. Specifically, during the remediation process for .env secret disclosures, the tool checks against a hard-coded limit of 20,000 findings before replacing resolved values with their corresponding variable references. This ordering error means that if an input file triggers more than this threshold, the system enters an early-stop path where it emits findings based on the currently processed state rather than the fully remediated state.
This logic flaw is exacerbated by specific structural characteristics in Docker Compose files, particularly when a pull request combines a secret-referencing image field with aliased content that expands into numerous individual entries or configurations. Such combinations can easily surpass the 20,000-finding threshold due to the combinatorial explosion of potential configuration permutations or nested variable expansions. When this limit is breached, the tool does not proceed to mask the sensitive data by substituting it with generic placeholders like environment variable names. Instead, it outputs the already graded findings containing the actual resolved secret values in plaintext. This leakage occurs across all supported output formats, including standard text logs, JSON reports, SARIF files for integration with development tools, and Code Scanning results, thereby maximizing the blast radius of the exposure within a CI/CD pipeline or local development environment.
The operational impact of this vulnerability is severe, as it directly compromises the confidentiality of sensitive credentials such as API keys, database passwords, or cloud provider tokens that are stored in sibling .env files. Exploitation requires an attacker to have control over the input being linted, typically achieved by submitting a pull request that writes secrets into the associated .env file and subsequently triggers the linter on untrusted changes. The tool's default behavior of exiting with code 2 upon hitting this limit might provide some incidental mitigation for automated systems that strictly check exit codes, but it does not prevent the leakage if logs are captured or if the --allow-partial-coverage flag is utilized to bypass the hard stop. This scenario aligns with CWE-798: Use of Hard-coded Credentials and CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, as the tool inadvertently acts as a vector for leaking credentials that were intended to be protected by its own security checks.
From a threat modeling perspective using MITRE ATT&CK frameworks, this vulnerability facilitates Credential Access via Local Log Scrubbing or Output Capture (T1530) and potentially Information Collection through automated pipeline artifacts (T1082). The attacker leverages the trusted nature of the linter to extract secrets that would otherwise remain hidden. To mitigate this risk, organizations must ensure they are running compose-lint version 0.33.0 or later, where the logic has been corrected to enforce remediation before limit checks or to properly mask outputs even when limits are exceeded. Additionally, defensive measures should include restricting access to CI/CD logs and output artifacts, implementing strict input validation for pull requests that modify configuration files, and avoiding the use of --allow-partial-coverage in production pipelines unless absolutely necessary. Regular auditing of linter configurations and ensuring that secret management practices do not rely solely on linting tools but are reinforced by dedicated secrets management solutions further reduces the attack surface associated with such misconfigurations.