How severe is GHSA-r79c-pqj3-577x?

GHSA-r79c-pqj3-577x has a CVSS score of 8.8/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-r79c-pqj3-577x?

GHSA-r79c-pqj3-577x affects the following packages: super-linter/super-linter (GitHub Actions), super-linter/super-linter/slim (GitHub Actions). Ecosystems affected: GitHub Actions.

How do I fix GHSA-r79c-pqj3-577x?

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 GHSA-r79c-pqj3-577x is resolved across your whole dependency graph.

How do I detect GHSA-r79c-pqj3-577x in my GitHub Actions dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for super-linter/super-linter. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-r79c-pqj3-577x if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-r79c-pqj3-577x?

O3 pinpoints whether GHSA-r79c-pqj3-577x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-r79c-pqj3-577x actively exploited in the wild?

No public exploit code has been indexed for GHSA-r79c-pqj3-577x 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 GHSA-r79c-pqj3-577x?

GHSA-r79c-pqj3-577x has an EPSS (Exploit Prediction Scoring System) score of 1.3%, placing it in the 67th 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 GHSA-r79c-pqj3-577x?

GHSA-r79c-pqj3-577x is classified as CWE-77 (CWE-77). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-r79c-pqj3-577x published, and has it been updated?

GHSA-r79c-pqj3-577x was published on February 9, 2026 and was last updated on February 22, 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

GHSA-r79c-pqj3-577x

HIGH

Super-linter is vulnerable to command injection via crafted filenames in Super-linter Action

Also known asCVE-2026-25761

Published

Feb 9, 2026

Updated

Feb 22, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

EPSS Exploitation Probability

via FIRST.org ↗

1.3%probability of exploitation in next 30 days

Lower Risk67th percentile+1.28%

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.

Blast Radius

2 pkgs affected

📦super-linter/super-linter📦super-linter/super-linter/slim

Real-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_request events.
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

2 total 2 fixed

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 dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for super-linter/super-linter. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-r79c-pqj3-577x 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 pinpoints whether GHSA-r79c-pqj3-577x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-r79c-pqj3-577x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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 permissio

O3 Security · Impact-Aware SCA

Is GHSA-r79c-pqj3-577x in your dependencies?

O3 detects GHSA-r79c-pqj3-577x across GitHub Actions dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works