A Popular Coding Tool Has a Critical Flaw That Lets Hackers Take Over Your Server — And the Old Fix Doesn't Work

If your web application lets users interact with Git repositories — cloning, syncing, pulling — an attacker may be able to use that feature to take complete control of your server, and the patch you applied years ago to stop exactly this kind of attack isn't enough.

Who Is at Risk — and How Big Is This?

The vulnerable library is called simple-git, a JavaScript package that developers use to talk to the Git version-control system from inside their applications. It is one of the most widely used Git wrappers in the Node.js ecosystem, downloaded over 50 million times per month on npm. It powers CI/CD pipelines, developer dashboards, code hosting platforms, automated deployment tools, and countless internal web apps at companies of every size.

If your organization runs any Node.js-based application that touches Git — and statistically, there is a very good chance it does — this vulnerability deserves your immediate attention. The flaw is rated 9.8 out of 10 (CRITICAL) on the industry standard severity scale, the highest tier reserved for bugs that are easy to exploit and catastrophic in impact. It affects every version of simple-git before 3.36.0 across Windows, macOS, and Linux.

What the Attacker Can Actually Do

Imagine your company runs a web service that lets users import a project by pasting in a Git repository address. Maybe it's a deployment tool, a portfolio builder, or an internal automation platform. Behind the scenes, your application takes that address and hands it to simple-git to do the cloning. This is completely normal and incredibly common. Now imagine an attacker doesn't paste in a legitimate repository address — instead, they paste in a carefully crafted string of text that isn't really an address at all, but a disguised set of instructions. Because simple-git passes options and inputs to Git without fully sanitizing them, Git obediently follows those instructions. The attacker's code runs on your server as if your own application executed it.

What can they do with that? Anything your server can do. Steal database credentials sitting in environment variables. Exfiltrate private source code. Install a persistent backdoor. Pivot deeper into your internal network. Encrypt your files for ransom. The specific technique here involves abusing Git's lesser-known "ext" protocol — a feature that allows Git to hand off transport operations to an arbitrary external command. By enabling this protocol through a configuration flag smuggled inside user input, an attacker can point Git at a shell command instead of a repository, and Git will run it without complaint.

The reason this vulnerability exists again is particularly frustrating: this is not a new class of attack. The exact same abuse was patched back in 2022 under a previous vulnerability report. That fix told simple-git to block any options containing -c, the short form of Git's configuration flag. Developers breathed a sigh of relief, patched their apps, and moved on. But the fix never accounted for the long form of that same flag: --config. One extra word, and the entire protection evaporates. It is the digital equivalent of locking your front door but leaving the back door wide open because it has a different handle.

The Technical Anchor Security Teams Need to Know

The vulnerability class is argument injection leading to Remote Code Execution via Git's ext:: protocol handler. The attack chain requires two conditions: first, the attacker smuggles the --config protocol.ext.allow=always flag through unsanitized input into simple-git's options argument; second, they supply an ext::<shell-command> clone source. Because the --config long-form equivalent was not blocked by the incomplete patch for CVE-2022-25912, the blocklist in versions prior to 3.36.0 is trivially bypassed. The CVSS score is 9.8 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), reflecting network-reachable, zero-authentication, zero-user-interaction exploitation.

Has This Been Used in the Wild?

As of publication, no confirmed active exploitation has been reported. There are no known threat actor campaigns, no public proof-of-concept exploit code circulating in mainstream forums, and no named victims. However, security teams should treat this as a short window, not an all-clear signal. The original 2022 vulnerability it bypasses was well-documented and understood, meaning anyone who researched that attack has a substantial head start on weaponizing this variant. The bypass technique — swapping -c for --config — is simple enough that the gap between disclosure and exploitation is likely to be short.

The vulnerability was surfaced through coordinated research into the completeness of the original CVE-2022-25912 remediation, a pattern of "incomplete fix" discovery that has become increasingly common as security researchers revisit old patches with fresh eyes. The maintainers of simple-git have responded with version 3.36.0, which addresses the bypass.

What You Should Do Right Now

1. Update simple-git to version 3.36.0 or later — today.
   Run npm install simple-git@latest or yarn upgrade simple-git in any project that uses the library. Then check your package-lock.json or yarn.lock for transitive dependencies — other packages your project relies on that may themselves depend on an older version of simple-git. Run npm ls simple-git to surface every copy in your dependency tree and confirm all of them are 3.36.0 or above.
2. Audit every place your application passes external or user-supplied input to simple-git.
   Search your codebase for calls to simpleGit().clone(), .pull(), .fetch(), and any method that accepts an options object. If any of those values — the repository URL, branch name, configuration flags — can be influenced by user input, API parameters, webhook payloads, or third-party data, treat that pathway as potentially exploitable. Apply a strict allowlist of acceptable repository URL formats (e.g., only https:// URLs pointing to known domains) and reject anything that does not match exactly.
3. Add a runtime guardrail by blocking the ext:: protocol at the network and Git configuration level.
   On servers running your application, set the global Git configuration git config --global protocol.ext.allow never. This disables the ext protocol system-wide, cutting off the specific mechanism this attack relies on. For containerized environments, bake this into your base image's startup configuration. Additionally, consider adding a Web Application Firewall rule or input validation middleware that rejects any input string containing substrings like ext::, --config, or protocol.ext before it ever reaches your application logic.

The Bigger Picture

This vulnerability is a reminder that "patched" is not the same as "fixed." Security mitigations built on blocklists — blocking specific known-bad strings or flags — are inherently brittle, because they assume attackers will only ever use the exact form of an attack that was previously documented. Real attackers iterate. They read patch notes. They look for synonyms, aliases, and equivalent forms that the original defender never considered. The -c versus --config bypass is almost insultingly simple in hindsight, which is exactly what makes it so dangerous: it requires no advanced knowledge, no zero-day research, just the ability to read Git documentation.

If your security program relies on library patches as a primary line of defense, this is a good moment to invest in secondary controls — input validation, least-privilege service accounts, network egress filtering, and runtime security monitoring — so that when the next incomplete patch emerges, your infrastructure isn't a single --config flag away from compromise.

CVE-2026-6951 | CVSS 9.8 CRITICAL | Affects simple-git < 3.36.0 | Fix: upgrade to 3.36.0+