GHSA-XCF7-88G6-7XR8
Vulnerability from github – Published: 2026-11-10 21:50 – Updated: 2026-11-10 21:50Impact
In Action tags v0.30.0 and v0.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. In v0.31.0 that message is outside the window in which the Action turns command processing off, and v0.30.0 has no such window. A pull request can commit a symlink on that path to a directory whose name contains a newline followed by a command.
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.
Only the Action is affected, and only when sarif-file: points into a subdirectory. The documented setup, sarif-file: results.sarif at the repository root, is not affected. The compose-lint package, the pre-commit hook and the Docker image do not print this message.
Found during an internal pre-1.0 security review. It was first published as part of GHSA-r7j4-crjv-h467, together with four other gaps in the same fix. Each gap now has its own advisory.
Patches
Fixed in 0.32.0. The SARIF-directory error names the sarif-file: input as written.
Workarounds
- Upgrade to 0.32.0 or later.
- Keep
sarif-fileat the workspace root, for examplesarif-file: results.sarif.
Reproduction
On a GitHub-hosted runner (runner 2.337.0), the Action at v0.31.0 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, creates an annotation. With sarif-file at the repository root it creates none.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.31.0"
},
"package": {
"ecosystem": "GitHub Actions",
"name": "tmatens/compose-lint"
},
"ranges": [
{
"events": [
{
"introduced": "0.30.0"
},
{
"fixed": "0.32.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-125125"
],
"database_specific": {
"cwe_ids": [
"CWE-117",
"CWE-150"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-10T21:50:54Z",
"nvd_published_at": "2026-11-10T17:17:27Z",
"severity": "LOW"
},
"details": "### Impact\n\nIn Action tags v0.30.0 and v0.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. In v0.31.0 that message is outside the window in which the Action turns command processing off, and v0.30.0 has no such window. A pull request can commit a symlink on that path to a directory whose name contains a newline followed by a command.\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\nOnly the Action is affected, and only when `sarif-file:` points into a subdirectory. The documented setup, `sarif-file: results.sarif` at the repository root, is not affected. The `compose-lint` package, the pre-commit hook and the Docker image do not print this message.\n\nFound during an internal pre-1.0 security review. It was first published as part of GHSA-r7j4-crjv-h467, together with four other gaps in the same fix. Each gap now has its own advisory.\n\n### Patches\n\nFixed in 0.32.0. The SARIF-directory error names the `sarif-file:` input as written.\n\n### Workarounds\n\n- Upgrade to 0.32.0 or later.\n- Keep `sarif-file` at the workspace root, for example `sarif-file: results.sarif`.\n\n### Reproduction\n\nOn a GitHub-hosted runner (runner 2.337.0), the Action at v0.31.0 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`, creates an annotation. With `sarif-file` at the repository root it creates none.",
"id": "GHSA-xcf7-88g6-7xr8",
"modified": "2026-11-10T21:50:55Z",
"published": "2026-11-10T21:50:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tmatens/compose-lint/security/advisories/GHSA-xcf7-88g6-7xr8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-125125"
},
{
"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:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "\u00a0compose-lint: Workflow command injection through SARIF-directory errors triggered by pull request symlinks\u00a0"
}
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.
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
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…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.