https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 23:10:36 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-102827 <p>simple-git, an interface for running git commands in any node.js application, enables applications to execute Git operations from JavaScript. Prior to 4.0.0, the default blockUnsafeOperationsPlugin compares parsed option names with literal dangerous option spellings while Git accepts unambiguous long-option abbreviations. Attacker-influenced push arguments such as abbreviated --receive-pack or --exec forms can therefore bypass detectVulnerableFlags, reach git push against a local or file remote or an attacker-influenced receive-pack target, and cause Git to invoke an attacker-selected command in consumers that expose those arguments. The clone-side abbreviation handling does not protect the push path. This issue is fixed in 4.0.0.</p> <p>simple-git, an interface for running git commands in any node.js application, enables applications to execute Git operations from JavaScript. Prior to 4.0.0, the default blockUnsafeOperationsPlugin compares parsed option names with literal dangerous option spellings while Git accepts unambiguous long-option abbreviations. Attacker-influenced push arguments such as abbreviated --receive-pack or --exec forms can therefore bypass detectVulnerableFlags, reach git push against a local or file remote or an attacker-influenced receive-pack target, and cause Git to invoke an attacker-selected command in consumers that expose those arguments. The clone-side abbreviation handling does not protect the push path. This issue is fixed in 4.0.0.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-102827 https://vulnerability.circl.lu/vuln/ghsa-858h-whjf-mvg5 <p><strong>Affected:</strong> npm: simple-git</p> <p>simple-git&#39;s blockUnsafeOperationsPlugin blocks dangerous git options (--upload-pack/--receive-pack/--exec/...) unless the consumer opts in via unsafe:{allowUnsafePack:true}. Detection (@simple-git/argv-parser detectVulnerableFlags) matches the parsed flag NAME against literal-spelling patterns: /--(upload|receive)-pack/ (requires the literal &#39;-pack&#39;) and the string &#39;--exec&#39;. But git accepts unambiguous prefix abbreviations of long options, and expandToken (token-expander.ts) returns the LITERAL token as flag.name (it uses the spec only for needsNext, never to canonicalize). So `git push --receive-p=&lt;cmd&gt;` parses with flag.name=&#39;--receive-p&#39;, which /--(upload|receive)-pack/ does NOT match, yet git expands --receive-p -&gt; --receive-pack and runs &lt;cmd&gt; (on a local/file remote, locally). The clone side is robust (its &#39;--u&#39; substring rule catches every --upload* abbreviation); the push --receive-* and --exe* abbreviations have no equivalent rule and slip through.</p> <p>Proof of concept (latest: simple-git 3.36.0, @simple-git/argv-parser 1.1.1, default unsafe plugin ON): Gate vulnerabilityCheck: &#39;push --receive-pack=touch...&#39; -&gt; BLOCKED; &#39;push --receive-pa=touch...&#39; and &#39;push --receive-p=touch...&#39; -&gt; BYPASS (empty vulns); &#39;--exec=&#39; BLOCKED, &#39;--exe=&#39; BYPASS. End-to-end via simpleGit().push(): CONTROL git.push([&#39;../bare&#39;,&#39;HEAD:refs/heads/c&#39;,&#39;--receive-pack=touch /tmp/pwned_ctrl;&#39;]) -&gt; throws GitPluginError &#39;Use of --upload-pack or --receive-pack is not permitted...&#39;; no command runs.…</p> <p><strong>Affected:</strong> npm: simple-git</p> <p>simple-git&#39;s blockUnsafeOperationsPlugin blocks dangerous git options (--upload-pack/--receive-pack/--exec/...) unless the consumer opts in via unsafe:{allowUnsafePack:true}. Detection (@simple-git/argv-parser detectVulnerableFlags) matches the parsed flag NAME against literal-spelling patterns: /--(upload|receive)-pack/ (requires the literal &#39;-pack&#39;) and the string &#39;--exec&#39;. But git accepts unambiguous prefix abbreviations of long options, and expandToken (token-expander.ts) returns the LITERAL token as flag.name (it uses the spec only for needsNext, never to canonicalize). So `git push --receive-p=&lt;cmd&gt;` parses with flag.name=&#39;--receive-p&#39;, which /--(upload|receive)-pack/ does NOT match, yet git expands --receive-p -&gt; --receive-pack and runs &lt;cmd&gt; (on a local/file remote, locally). The clone side is robust (its &#39;--u&#39; substring rule catches every --upload* abbreviation); the push --receive-* and --exe* abbreviations have no equivalent rule and slip through.</p> <p>Proof of concept (latest: simple-git 3.36.0, @simple-git/argv-parser 1.1.1, default unsafe plugin ON): Gate vulnerabilityCheck: &#39;push --receive-pack=touch...&#39; -&gt; BLOCKED; &#39;push --receive-pa=touch...&#39; and &#39;push --receive-p=touch...&#39; -&gt; BYPASS (empty vulns); &#39;--exec=&#39; BLOCKED, &#39;--exe=&#39; BYPASS. End-to-end via simpleGit().push(): CONTROL git.push([&#39;../bare&#39;,&#39;HEAD:refs/heads/c&#39;,&#39;--receive-pack=touch /tmp/pwned_ctrl;&#39;]) -&gt; throws GitPluginError &#39;Use of --upload-pack or --receive-pack is not permitted...&#39;; no command runs.…</p> https://vulnerability.circl.lu/vuln/ghsa-858h-whjf-mvg5