CVE-2026-25761 — super-linter/super-linter
HIGHCVE-2026-25761 is a high-severity (CVSS 8.8) CWE-77 vulnerability in super-linter/super-linter. A fix is available for super-linter/super-linter — see the affected versions and patch details below.
Command injection via crafted filenames in Super-linter Action
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-25761.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-25761 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
super-linter/super-linter📦super-linter/super-linter/slimReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects GitHub Actions packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The Super-linter GitHub Action is vulnerable to command injection via crafted filenames. When this action is used in downstream GitHub Actions workflows, an attacker can submit a pull request that introduces a file whose name contains shell command substitution syntax, such as $(...). In affected Super-linter versions, runtime scripts may execute the embedded command during file discovery processing, enabling arbitrary command execution in the workflow runner context. This can be used to disclose the job’s GITHUB_TOKEN depending on how the workflow configures permissions.
Details
The issue appears originates in the logic that scans the repository for changed files to check.
- Use a workflow that runs Super-linter on
pull_requestevents. - Open a pull request that adds a new file with a crafted filename containing command substitution and an outbound request that includes
$GITHUB_TOKEN. - Run the workflow.
Impact
- Arbitrary command execution in the context of the workflow run that invokes Super-linter (triggered by attacker-controlled filenames in a PR).
- Credential exposure / misuse: the injected command can read environment variables available to the action, including
GITHUB_TOKEN.
The level of exposure depends on the source of the pull request.
To actively exploit the vulnerability, an attacker needs have the ability to run workflows without any approval from the repository admin.
Also, the GITHUB_TOKEN needs to have unconstrained access to repository resources. Even in that case, for pull request coming from forked repositories, no secrets are passed to the forked repository when running workflows triggered by pull_request events, and the GITHUB_TOKEN drops and write permission on the source repository source.
Finally, although not specific to this vulnerability, we recommend auditing workflow_call and pull_request_target workflows because they can lead to compromise, regardless of whether you're using Super-linter, or not, as explained by this GitHub Enterprise doc.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦GitHub Actions | super-linter/super-linter | ≥ 6.0.0&&< 8.3.1 | 8.3.1 |
| 📦GitHub Actions | super-linter/super-linter/slim | ≥ 6.0.0&&< 8.3.1 | 8.3.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for super-linter/super-linter, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update super-linter/super-linter to 8.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-25761 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-25761 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-25761. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-25761 in your dependencies?
O3 Security finds CVE-2026-25761 across GitHub Actions dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.