CVE-2026-6951

What it actually does

simple-git versions before 3.36.0 can allow command execution when application-controlled or user-controlled input is passed into the simple-git options argument. The attempted fix for an earlier issue blocked the short Git configuration flag, -c, but did not block the equivalent long form, --config. An attacker can use --config to set protocol.ext.allow=always and then supply an ext:: Git transport URL, causing Git to invoke an external command through the git-remote-ext mechanism. In affected applications, this can result in remote code execution with the privileges of the Node.js application process.

Why it matters to the business

Successful exploitation can let an unauthenticated remote attacker run arbitrary commands on servers that use simple-git with untrusted option input, potentially leading to service compromise, data theft, malware deployment, source-code exposure, credential theft, or lateral movement. Although this issue is not currently listed in CISA KEV and has low EPSS at the time of assessment, the CVSS severity is critical and the vulnerable package is commonly used in JavaScript/Node.js automation, CI/CD, repository management, and developer tooling, so exposure should be treated as high priority where external input can influence Git operations.

How an attack unfolds

An attacker first identifies an application feature that performs Git operations through simple-git, such as cloning, fetching, checking repository status, validating repository URLs, importing projects, or processing user-supplied repository metadata. If the application passes attacker-controlled values into the options argument, the attacker provides the long-form Git configuration option --config rather than the blocked -c form. They use it to enable protocol.ext.allow=always, which permits Git's ext:: transport. The attacker then supplies an ext:: repository URL crafted to execute a command through Git's external transport helper. When the application invokes simple-git, simple-git launches the Git CLI with the attacker-controlled option and source. Git honors the configuration, processes the ext:: transport, and executes the embedded command as the application user. From there, the attacker may download additional payloads, read environment variables and secrets, modify application files, pivot to other systems, or establish persistence depending on the hosting environment and process privileges.

How to fix it

Upgrade simple-git to version 3.36.0 or later wherever it is used. Because the vulnerability depends on how applications pass input into simple-git, also review code paths that accept repository URLs, options arrays, configuration flags, branch names, or other Git parameters from users or upstream systems. Do not pass untrusted input into the simple-git options argument. Enforce strict allow-lists for permitted Git options and protocols; reject --config, -c, protocol.ext.allow, ext:: URLs, and other dynamic Git configuration mechanisms unless there is a compelling and safely isolated use case. If immediate upgrade is not possible, add input validation that blocks Git configuration flags and ext:: transports, run Git operations in a sandboxed/containerized environment with minimal privileges, remove access to sensitive environment variables, and apply outbound network restrictions. Rebuild and redeploy applications after dependency updates, including transitive dependency updates through lockfiles.

How to confirm the fix worked

Confirm that installed dependency versions are no longer vulnerable by inspecting package manifests and lockfiles, such as package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, or npm ls simple-git, and verify simple-git is 3.36.0 or later. Run software composition analysis in CI and against deployed artifacts to ensure no vulnerable versions remain. Review application code for simpleGit(...), .clone(), .raw(), .env(), .addConfig(), .customBinary(), and options-array usage where untrusted input may be included. Test validation controls by attempting to submit benign payloads containing --config, protocol.ext.allow=always, and ext:: and confirming they are rejected before Git execution. Where feasible, enable Git command auditing or wrapper logging to confirm runtime invocations do not include dangerous flags or transports.

Typical attack path

1. Find an exposed application workflow that invokes simple-git for clone, fetch, pull, ls-remote, status, or similar Git operations.
2. Determine whether user-controlled input can reach simple-git options, repository URLs, branch names, or command arguments without strict allow-listing.
3. Submit a crafted option using --config to set protocol.ext.allow=always.
4. Provide an ext:: Git URL or clone source containing an operating-system command payload.
5. Trigger the application to execute the Git operation through simple-git.
6. Git processes the attacker-supplied configuration and invokes the external transport helper, executing the payload as the Node.js application user.
7. Use the initial command execution to collect secrets, run reconnaissance, deploy malware, or move laterally.

How to detect it

To determine whether exploitation already occurred, review application logs for repository import, clone, fetch, or Git operation requests containing suspicious Git options or transports. Search web access logs, API gateway logs, reverse proxy logs, and application request logs for --config, protocol.ext.allow, and ext:: in parameters, JSON bodies, form fields, and encoded variants. Review process creation telemetry from Linux auditd, eBPF/EDR, container runtime logs, Windows Sysmon, or cloud workload telemetry for git processes spawned by node that include --config or protocol.ext.allow=always, and for unexpected child processes of git, git-remote-ext, sh, bash, curl, wget, python, perl, nc, or powershell. Examine CI/CD and build logs for unexpected Git clone sources beginning with ext::. Inspect container and host filesystems for newly created scripts, web shells, cron jobs, SSH authorized_keys changes, modified startup scripts, or downloaded payloads around the time of suspicious Git operations. If suspicious activity is found, preserve logs and affected containers/hosts, isolate the workload, collect process trees and command histories, and rotate secrets available to the Node.js process.

• --config
• protocol.ext.allow=always
• protocol.ext.allow
• ext::
• git-remote-ext
• git clone ext::
• git ls-remote ext::
• git fetch ext::
• git --config protocol.ext.allow=always
• node
• git
• sh -c
• bash -c
• curl
• wget
• nc -e
• ncat -e
• python -c
• perl -e
• powershell -enc
• authorized_keys
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Inventory all applications, CI jobs, developer portals, repository importers, automation services, and build systems that use the simple-git npm package.
• Prioritize remediation for internet-facing services and systems where users can submit repository URLs, project import requests, Git options, branch names, or other Git-related parameters.
• Upgrade simple-git to 3.36.0 or later and refresh lockfiles and deployed artifacts.
• Add server-side validation that blocks --config, -c, protocol.ext.allow, ext::, and unapproved Git protocols in all user-influenced Git workflows.
• Harden execution environments for Git operations by using least-privilege service accounts, containers or sandboxes, read-only filesystems where practical, and restricted outbound network access.
• Search logs and telemetry for historical use of ext:: transports, protocol.ext.allow, suspicious Git command lines, and child processes spawned by Git or Node.js.
• Rotate credentials exposed to affected application processes if exploitation is suspected, including tokens, SSH keys, cloud credentials, CI secrets, and repository access tokens.
• Add dependency scanning and policy gates to prevent reintroduction of simple-git versions before 3.36.0.