GHSA-R7J4-CRJV-H467

Vulnerability from github – Published: 2026-11-10 18:28 – Updated: 2026-11-10 18:28
VLAI
Summary
compose-lint: Text in a pull request can still issue CI workflow commands through compose-lint 0.31.0's output
Details

Impact

0.31.0 fixed GHSA-6f4g-xm8v-pgv6, where text from a Compose file became GitHub Actions workflow commands in compose-lint's output. The fix escapes the command openers in everything compose-lint prints, and the 0.31.0 changelog says the report "escapes both openers (also covering Azure Pipelines)". Five paths were left open:

  • Unicode whitespace before a line-leading ::. The runner strips all Unicode whitespace from the start of a line before it looks for a command. compose-lint only accounted for spaces and tabs, so a no-break space or another Unicode space ahead of :: is not escaped. It can come from a Compose value, or from a file name: the text report's file heading and per-file summary, and the fix summary on stderr, start with the path as given, so a directory named with a leading no-break space followed by :: puts a command at the start of a line. This reaches those lines, the text report's fix guidance, the fix dry-run diff, and continuation lines of stderr diagnostics.
  • JSON and SARIF printed to stdout. --format json and --format sarif output never passed through the sanitizer, so ##[ inside a service name or other value reaches the log intact when the output isn't redirected to a file.
  • Command-line errors. When a repository path reaches compose-lint's arguments without a -- before it, the argument parser prints it raw in its error message. That includes a carriage return, which the runner treats as a line break, so a command can also start a new line there.
  • Azure Pipelines. ##vso[ logging commands were not escaped on any path, despite the changelog's Azure claim.
  • An error message in the GitHub Action (0.30.0 and 0.31.0). When sarif-file: names a file in a subdirectory that can't be created, the Action prints the directory's resolved path in an error message, outside the window in which it turns command processing off. A pull request can commit a symlink on that path to a directory whose name contains a newline followed by a command. The documented setup, sarif-file: results.sarif at the repository root, is not affected.

A pull request can therefore create annotations, fold or hide parts of the job log, or issue other commands the runner accepts, when CI runs compose-lint over it, before anyone reviews it. The pass/fail result is not changed.

Affected setups are those that print compose-lint's output to a CI log without the GitHub Action: the compose-lint package run directly in a workflow, the pre-commit hook run in CI, and the Docker image. The pre-commit hook is affected in its default configuration: it passes each changed file's path to compose-lint, and a path whose directory name starts with Unicode whitespace and :: reaches the report's file heading. The JSON/SARIF and command-line paths also need output left on stdout, or args: without the documented trailing --, which is why they alone would score lower. The GitHub Action turns command processing off around each compose-lint run, so of these paths only its own error message affects it, and only when sarif-file: points into a subdirectory. That setup is outside the documented one, which is why that path alone would also score lower.

Found during an internal pre-1.0 security review.

Docker image. composelint/compose-lint tag 0.31.0, the matching minor tag, and latest are affected.

Releases before 0.31.0 are covered by GHSA-6f4g-xm8v-pgv6, except the Action's error message, which also affects Action 0.30.0.

Patches

Fixed in 0.32.0. The line-start escaping covers every character the runner strips before ::, so it holds for quoted values and file names alike. JSON and SARIF on stdout escape ##[ inside strings as \u005b, which decodes to the same data. argparse's own messages go through the same sanitizer. ##vso[ is escaped everywhere. In the Action, the SARIF-directory error names the sarif-file: input as written.

Workarounds

  • Upgrade to 0.32.0 or later.
  • On GitHub Actions, use the tmatens/compose-lint Action, or bracket the compose-lint step with ::stop-commands::<random token> and ::<token>::, as the Action does.
  • In the Action, keep sarif-file at the workspace root, for example sarif-file: results.sarif.
  • Write --format json and --format sarif output to a file rather than the log.
  • End the pre-commit hook's args: with --. This closes the command-line path only; it does not stop a file name at the start of a report line, so in CI also bracket the pre-commit step with ::stop-commands:: as above.
  • On Azure Pipelines, don't print compose-lint's output from runs over untrusted pull requests to the job log.

Reproduction

On compose-lint 0.31.0 on a GitHub-hosted runner (runner 2.337.0), each of the following creates an annotation:

  • a Compose file with image: "nginx\n\u00a0::notice::X", linted with the text report;
  • a directory named \u00a0::notice::X (a no-break space, then ::notice::X) holding a compose.yml, linted with compose-lint -- '<that directory>/compose.yml', or by the pre-commit hook in its default configuration;
  • a service named a##[warning]X, linted with --format json or --format sarif to stdout;
  • compose-lint '--##[warning]X/compose.yml' with no --;
  • the Action with sarif-file: out/reports/results.sarif, where out is a committed symlink to a directory named d\n::warning::X that contains a regular file reports.

The same inputs with a plain space in place of the no-break space, or with -- before the path, or with sarif-file at the repository root, create none. The same inputs on compose-lint 0.30.0 create annotations even with a plain space, which is GHSA-6f4g-xm8v-pgv6. The composelint/compose-lint:0.31.0 image produces byte-identical output to the package.

Severity
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "compose-lint"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.31.0"
            },
            {
              "fixed": "0.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-125121"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-11-10T18:28:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n0.31.0 fixed GHSA-6f4g-xm8v-pgv6, where text from a Compose file became GitHub Actions workflow commands in compose-lint\u0027s output. The fix escapes the command openers in everything compose-lint prints, and the 0.31.0 changelog says the report \"escapes both openers (also covering Azure Pipelines)\". Five paths were left open:\n\n- **Unicode whitespace before a line-leading `::`.** The runner strips all Unicode whitespace from the start of a line before it looks for a command. compose-lint only accounted for spaces and tabs, so a no-break space or another Unicode space ahead of `::` is not escaped. It can come from a Compose value, or from a file name: the text report\u0027s file heading and per-file summary, and the `fix` summary on stderr, start with the path as given, so a directory named with a leading no-break space followed by `::` puts a command at the start of a line. This reaches those lines, the text report\u0027s fix guidance, the `fix` dry-run diff, and continuation lines of stderr diagnostics.\n- **JSON and SARIF printed to stdout.** `--format json` and `--format sarif` output never passed through the sanitizer, so `##[` inside a service name or other value reaches the log intact when the output isn\u0027t redirected to a file.\n- **Command-line errors.** When a repository path reaches compose-lint\u0027s arguments without a `--` before it, the argument parser prints it raw in its error message. That includes a carriage return, which the runner treats as a line break, so a command can also start a new line there.\n- **Azure Pipelines.** `##vso[` logging commands were not escaped on any path, despite the changelog\u0027s Azure claim.\n- **An error message in the GitHub Action (0.30.0 and 0.31.0).** When `sarif-file:` names a file in a subdirectory that can\u0027t be created, the Action prints the directory\u0027s resolved path in an error message, outside the window in which it turns command processing off. A pull request can commit a symlink on that path to a directory whose name contains a newline followed by a command. The documented setup, `sarif-file: results.sarif` at the repository root, is not affected.\n\nA pull request can therefore create annotations, fold or hide parts of the job log, or issue other commands the runner accepts, when CI runs compose-lint over it, before anyone reviews it. The pass/fail result is not changed.\n\nAffected setups are those that print compose-lint\u0027s output to a CI log without the GitHub Action: the `compose-lint` package run directly in a workflow, the pre-commit hook run in CI, and the Docker image. The pre-commit hook is affected in its default configuration: it passes each changed file\u0027s path to compose-lint, and a path whose directory name starts with Unicode whitespace and `::` reaches the report\u0027s file heading. The JSON/SARIF and command-line paths also need output left on stdout, or `args:` without the documented trailing `--`, which is why they alone would score lower. The GitHub Action turns command processing off around each compose-lint run, so of these paths only its own error message affects it, and only when `sarif-file:` points into a subdirectory. That setup is outside the documented one, which is why that path alone would also score lower.\n\nFound during an internal pre-1.0 security review.\n\n**Docker image.** `composelint/compose-lint` tag 0.31.0, the matching minor tag, and `latest` are affected.\n\nReleases before 0.31.0 are covered by GHSA-6f4g-xm8v-pgv6, except the Action\u0027s error message, which also affects Action 0.30.0.\n\n### Patches\n\nFixed in 0.32.0. The line-start escaping covers every character the runner strips before `::`, so it holds for quoted values and file names alike. JSON and SARIF on stdout escape `##[` inside strings as `\\u005b`, which decodes to the same data. argparse\u0027s own messages go through the same sanitizer. `##vso[` is escaped everywhere. In the Action, the SARIF-directory error names the `sarif-file:` input as written.\n\n### Workarounds\n\n- Upgrade to 0.32.0 or later.\n- On GitHub Actions, use the `tmatens/compose-lint` Action, or bracket the compose-lint step with `::stop-commands::\u003crandom token\u003e` and `::\u003ctoken\u003e::`, as the Action does.\n- In the Action, keep `sarif-file` at the workspace root, for example `sarif-file: results.sarif`.\n- Write `--format json` and `--format sarif` output to a file rather than the log.\n- End the pre-commit hook\u0027s `args:` with `--`. This closes the command-line path only; it does not stop a file name at the start of a report line, so in CI also bracket the pre-commit step with `::stop-commands::` as above.\n- On Azure Pipelines, don\u0027t print compose-lint\u0027s output from runs over untrusted pull requests to the job log.\n\n### Reproduction\n\nOn compose-lint 0.31.0 on a GitHub-hosted runner (runner 2.337.0), each of the following creates an annotation:\n\n- a Compose file with `image: \"nginx\\n\\u00a0::notice::X\"`, linted with the text report;\n- a directory named `\\u00a0::notice::X` (a no-break space, then `::notice::X`) holding a `compose.yml`, linted with `compose-lint -- \u0027\u003cthat directory\u003e/compose.yml\u0027`, or by the pre-commit hook in its default configuration;\n- a service named `a##[warning]X`, linted with `--format json` or `--format sarif` to stdout;\n- `compose-lint \u0027--##[warning]X/compose.yml\u0027` with no `--`;\n- the Action with `sarif-file: out/reports/results.sarif`, where `out` is a committed symlink to a directory named `d\\n::warning::X` that contains a regular file `reports`.\n\nThe same inputs with a plain space in place of the no-break space, or with `--` before the path, or with `sarif-file` at the repository root, create none. The same inputs on compose-lint 0.30.0 create annotations even with a plain space, which is GHSA-6f4g-xm8v-pgv6. The `composelint/compose-lint:0.31.0` image produces byte-identical output to the package.",
  "id": "GHSA-r7j4-crjv-h467",
  "modified": "2026-11-10T18:28:36Z",
  "published": "2026-11-10T18:28:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tmatens/compose-lint/security/advisories/GHSA-r7j4-crjv-h467"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tmatens/compose-lint/pull/945"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tmatens/compose-lint/commit/542e63126f795564a65c63887ea0dc558a500688"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tmatens/compose-lint"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tmatens/compose-lint/releases/tag/v0.32.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "compose-lint: Text in a pull request can still issue CI workflow commands through compose-lint 0.31.0\u0027s output"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.