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.
732 vulnerabilities reference this CWE, most recent first.
GHSA-C6MW-8XH8-GPQ6
Vulnerability from github – Published: 2026-09-04 18:11 – Updated: 2026-09-04 18:11Maintainer resolution
The CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 9a34b5034d29f05d1f28fa61b04719ca6a741020. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.
Argument Injection in git_blame Tool Allows Arbitrary File Read Without Approval
Overview
The git_blame tool in DeepSeek-TUI passes the model-supplied rev parameter unvalidated into the argv of git blame. git blame accepts --contents=<file>, which causes it to use the file's contents in place of the working tree and echo each line verbatim in the blame output. A rev value of --contents=/path/to/secret therefore exfiltrates the targeted file's contents into the tool result, which is returned to the model and displayed in the chat transcript.
The tool is registered with ApprovalRequirement::Auto and declares ToolCapability::ReadOnly. The read is in-scope for the capability label, but the target of the read is not the user expects git_blame to read files inside the workspace, not arbitrary paths on the host.
This is a sibling of the git_show argument-injection vulnerability filed separately, sharing the same root cause (missing --end-of-options sentinel and unvalidated rev).
Impact
Arbitrary file read at the privilege of the user running DeepSeek-TUI, via malicious repository content combined with prompt injection (the threat model already documented in CVE-2026-45311).
Reachable as the invoking user:
~/.ssh/id_rsa,~/.ssh/id_ed25519, and other private keys~/.aws/credentials,~/.config/gh/hosts.yml,~/.netrc.envfiles anywhere in the filesystem- Any project file outside the workspace the tool would normally restrict to
The leaked contents land in the model's context. The same model that obeyed the prompt-injection in step one can be instructed to forward the leak via fetch_url (network-policy permitting), summarize it in chat, or write it into a tool output the attacker can later retrieve.
Technical Details
Root Cause
crates/tui/src/tools/git_history.rs:
// L314-316
fn approval_requirement(&self) -> ApprovalRequirement {
ApprovalRequirement::Auto
}
// L322-358 (excerpt)
async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> {
let path_str = required_str(&input, "path")?;
let resolved_path = context.resolve_path(path_str)?; // path is bounded to workspace
...
let rev = optional_str(&input, "rev").unwrap_or("HEAD"); // rev is NOT bounded
...
let mut args = vec![
"blame".to_string(),
"--date=iso".to_string(),
format!("-L{start_line},{end_line}"),
];
if porcelain { args.push("--line-porcelain".to_string()); }
args.push(rev.to_string()); // unvalidated, no sentinel
args.push("--".to_string());
args.push(pathspec.display().to_string());
...
}
path correctly flows through context.resolve_path, which enforces workspace containment (spec.rs:342). rev does not and the -- separator after rev only ends pathspec parsing, it does not stop option parsing of rev itself.
The JSON schema for rev (L283-285) is {"type": "string"} with no constraints.
Why --contents Works
git blame --contents=<file> -- <pathspec> blames the working tree path as if its contents were the supplied file. Each line of the supplied file appears verbatim in the porcelain or human-readable output, prefixed with the attribution marker 00000000 (External file (--contents) <date> N). The full line content is preserved.
Two secondary primitives in the same parser also leak data, with smaller yield:
--ignore-revs-file=<file>: surfaces parse errors that disclose partial content when the file is not a valid revs list.-S <file>,--reverse <rev1>..<rev2>: not directly exploitable for read but expand the option surface that argv injection can reach.
Proof of Concept
Argv assembled by the tool with input
{"path": "a.txt", "rev": "--contents=/home/a/.ssh/id_rsa"}:
git blame --date=iso -L1,200 --contents=/home/a/.ssh/id_rsa -- a.txt
Reproduced against system git as a non-root user:
$ id
uid=1001(a) gid=1001(a) groups=1001(a)
$ echo "PRIVATEKEYDATA" > /home/a/.ssh/id_rsa
$ chmod 600 /home/a/.ssh/id_rsa
$ git blame --date=iso -L1,5 "--contents=/home/a/.ssh/id_rsa" -- a.txt
00000000 (External file (--contents) 2026-05-19 07:05:51 -0400 1) PRIVATEKEYDATA
A non-readable target (/etc/shadow, owned by root with mode 0640) returns Permission denied, confirming the read is bounded by uid as expected; this is not a privilege boundary bypass, it is the desktop user's own filesystem view being exposed past the workspace boundary the tool's path argument otherwise enforces.
End-to-end exploitation is identical to the git_show companion: malicious repo → AGENTS.md injection → model calls git_blame with the crafted rev → auto-approval → leaked content returned in tool output and consumed by the model.
Remediation
Same shape as the git_show fix:
args.push("--end-of-options".to_string());
args.push(rev.to_string());
args.push("--".to_string());
args.push(pathspec.display().to_string());
Plus a leading-hyphen rejection on rev. A regression test should pin both rev = "--contents=/etc/passwd" and rev = "--ignore-revs-file=/etc/passwd" as rejected inputs.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.27"
},
{
"last_affected": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.27"
},
{
"fixed": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "codewhale-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "codewhale"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-75912"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-04T18:11:45Z",
"nvd_published_at": "2026-08-18T16:18:23Z",
"severity": "HIGH"
},
"details": "### Maintainer resolution\n\nThe CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 9a34b5034d29f05d1f28fa61b04719ca6a741020. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.\n\n# Argument Injection in `git_blame` Tool Allows Arbitrary File Read Without Approval\n\n## Overview\n\nThe `git_blame` tool in DeepSeek-TUI passes the model-supplied `rev` parameter unvalidated into the argv of `git blame`. `git blame` accepts `--contents=\u003cfile\u003e`, which causes it to use the file\u0027s contents in place of the working tree and echo each line verbatim in the blame output. A `rev` value of `--contents=/path/to/secret` therefore exfiltrates the targeted file\u0027s contents into the tool result, which is returned to the model and displayed in the chat transcript.\n\nThe tool is registered with `ApprovalRequirement::Auto` and declares `ToolCapability::ReadOnly`. The read is in-scope for the capability label, but the *target* of the read is not the user expects `git_blame` to read files inside the workspace, not arbitrary paths on the host.\n\nThis is a sibling of the `git_show` argument-injection vulnerability filed separately, sharing the same root cause (missing `--end-of-options` sentinel and unvalidated `rev`).\n\n## Impact\n\nArbitrary file read at the privilege of the user running DeepSeek-TUI, via malicious repository content combined with prompt injection (the threat model already documented in CVE-2026-45311).\n\nReachable as the invoking user:\n\n- `~/.ssh/id_rsa`, `~/.ssh/id_ed25519`, and other private keys\n- `~/.aws/credentials`, `~/.config/gh/hosts.yml`, `~/.netrc`\n- `.env` files anywhere in the filesystem\n- Any project file outside the workspace the tool would normally restrict to\n\nThe leaked contents land in the model\u0027s context. The same model that obeyed the prompt-injection in step one can be instructed to forward the leak via `fetch_url` (network-policy permitting), summarize it in chat, or write it into a tool output the attacker can later retrieve.\n\n## Technical Details\n\n### Root Cause\n\n`crates/tui/src/tools/git_history.rs`:\n\n```rust\n// L314-316\nfn approval_requirement(\u0026self) -\u003e ApprovalRequirement {\n ApprovalRequirement::Auto\n}\n\n// L322-358 (excerpt)\nasync fn execute(\u0026self, input: Value, context: \u0026ToolContext) -\u003e Result\u003cToolResult, ToolError\u003e {\n let path_str = required_str(\u0026input, \"path\")?;\n let resolved_path = context.resolve_path(path_str)?; // path is bounded to workspace\n ...\n let rev = optional_str(\u0026input, \"rev\").unwrap_or(\"HEAD\"); // rev is NOT bounded\n ...\n let mut args = vec![\n \"blame\".to_string(),\n \"--date=iso\".to_string(),\n format!(\"-L{start_line},{end_line}\"),\n ];\n if porcelain { args.push(\"--line-porcelain\".to_string()); }\n args.push(rev.to_string()); // unvalidated, no sentinel\n args.push(\"--\".to_string());\n args.push(pathspec.display().to_string());\n ...\n}\n```\n\n`path` correctly flows through `context.resolve_path`, which enforces workspace containment (`spec.rs:342`). `rev` does not and the `--` separator after `rev` only ends pathspec parsing, it does not stop option parsing of `rev` itself.\n\nThe JSON schema for `rev` (L283-285) is `{\"type\": \"string\"}` with no constraints.\n\n### Why `--contents` Works\n\n`git blame --contents=\u003cfile\u003e -- \u003cpathspec\u003e` blames the working tree path *as if its contents were the supplied file*. Each line of the supplied file appears verbatim in the porcelain or human-readable output, prefixed with the attribution marker `00000000 (External file (--contents) \u003cdate\u003e N)`. The full line content is preserved.\n\nTwo secondary primitives in the same parser also leak data, with smaller\nyield:\n\n- `--ignore-revs-file=\u003cfile\u003e` : surfaces parse errors that disclose partial content when the file is not a valid revs list.\n- `-S \u003cfile\u003e`, `--reverse \u003crev1\u003e..\u003crev2\u003e` : not directly exploitable for read but expand the option surface that argv injection can reach.\n\n## Proof of Concept\n\nArgv assembled by the tool with input\n`{\"path\": \"a.txt\", \"rev\": \"--contents=/home/a/.ssh/id_rsa\"}`:\n\n```\ngit blame --date=iso -L1,200 --contents=/home/a/.ssh/id_rsa -- a.txt\n```\n\nReproduced against system `git` as a non-root user:\n\n```\n$ id\nuid=1001(a) gid=1001(a) groups=1001(a)\n\n$ echo \"PRIVATEKEYDATA\" \u003e /home/a/.ssh/id_rsa\n$ chmod 600 /home/a/.ssh/id_rsa\n\n$ git blame --date=iso -L1,5 \"--contents=/home/a/.ssh/id_rsa\" -- a.txt\n00000000 (External file (--contents) 2026-05-19 07:05:51 -0400 1) PRIVATEKEYDATA\n```\n\nA non-readable target (`/etc/shadow`, owned by root with mode 0640) returns `Permission denied`, confirming the read is bounded by uid as expected; this is not a privilege boundary bypass, it is the desktop user\u0027s own filesystem view being exposed past the workspace boundary the tool\u0027s `path` argument otherwise enforces.\n\nEnd-to-end exploitation is identical to the `git_show` companion: malicious repo \u2192 `AGENTS.md` injection \u2192 model calls `git_blame` with the crafted `rev` \u2192 auto-approval \u2192 leaked content returned in tool output and consumed by the model.\n\n## Remediation\n\nSame shape as the `git_show` fix:\n\n```rust\nargs.push(\"--end-of-options\".to_string());\nargs.push(rev.to_string());\nargs.push(\"--\".to_string());\nargs.push(pathspec.display().to_string());\n```\n\nPlus a leading-hyphen rejection on `rev`. A regression test should pin both `rev = \"--contents=/etc/passwd\"` and `rev = \"--ignore-revs-file=/etc/passwd\"` as rejected inputs.",
"id": "GHSA-c6mw-8xh8-gpq6",
"modified": "2026-09-04T18:11:45Z",
"published": "2026-09-04T18:11:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/security/advisories/GHSA-c6mw-8xh8-gpq6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75912"
},
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/commit/9a34b5034d29f05d1f28fa61b04719ca6a741020"
},
{
"type": "PACKAGE",
"url": "https://github.com/Hmbown/CodeWhale"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/codewhale-before-argument-injection-via-git-blame"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CodeWhale: Argument Injection in `git_blame` Tool Allows Arbitrary File Read Without Approval"
}
GHSA-CCCX-M78H-M3XW
Vulnerability from github – Published: 2026-04-14 00:31 – Updated: 2026-08-05 03:30Mitgation of CVE-2026-4519 was incomplete. If the URL contained "%action" the mitigation could be bypassed for certain browser types the "webbrowser.open()" API could have commands injected into the underlying shell. See CVE-2026-4519 for details.
{
"affected": [],
"aliases": [
"CVE-2026-4786"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-13T22:16:30Z",
"severity": "HIGH"
},
"details": "Mitgation of\u00a0CVE-2026-4519 was incomplete. If the URL contained \"%action\" the mitigation could be bypassed for certain browser types the \"webbrowser.open()\" API could have commands injected into the underlying shell. See\u00a0CVE-2026-4519 for details.",
"id": "GHSA-cccx-m78h-m3xw",
"modified": "2026-08-05T03:30:22Z",
"published": "2026-04-14T00:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4786"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/issues/148169"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/pull/148170"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/f4654824ae0850ac87227fb270f9057477946769"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/d6d68494be70bdbda20f89f83801ba52ec37daa4"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/d22922c8a7958353689dc4763dd72da2dea03fff"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/c5767a72838a8dda9d6dc5d3558075b055c56bca"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/a4d3edf3a6ecfde504d02126410d2a65a859b744"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/28b4ad38067bbdad34edfcd03ad2de5f06387e53"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30087"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30078"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28581"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28247"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26187"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25096"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22144"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21682"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21275"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19590"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10117"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30088"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30089"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:35838"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8822"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8824"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9228"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-4786"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2458049"
},
{
"type": "WEB",
"url": "https://mail.python.org/archives/list/security-announce@python.org/thread/JQDUNJVB4AQNTJECSUKOBDU3XCJIPSE5"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-4786.json"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10140"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10141"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10711"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10745"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10774"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10949"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10950"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11062"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11077"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11768"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13692"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13812"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14652"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14653"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14656"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:16699"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:17525"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:17619"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19019"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19064"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19175"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19176"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19177"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19216"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19549"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19570"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19571"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19576"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19589"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/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:X",
"type": "CVSS_V4"
}
]
}
GHSA-CFHX-3WMQ-Q5RG
Vulnerability from github – Published: 2025-03-26 00:31 – Updated: 2025-03-26 00:31A vulnerability was found in Pagure. An argument injection in Git during retrieval of the repository history leads to remote code execution on the Pagure instance.
{
"affected": [],
"aliases": [
"CVE-2024-47516"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-26T00:15:13Z",
"severity": "CRITICAL"
},
"details": "A vulnerability was found in Pagure. An argument injection in Git during retrieval of the repository history leads to remote code execution on the Pagure instance.",
"id": "GHSA-cfhx-3wmq-q5rg",
"modified": "2025-03-26T00:31:19Z",
"published": "2025-03-26T00:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47516"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-47516"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2315805"
}
],
"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"
}
]
}
GHSA-CGWQ-JPH9-CVC2
Vulnerability from github – Published: 2025-06-08 21:30 – Updated: 2025-06-08 21:30The Quantenna Wi-Fi chipset ships with a local control script, router_command.sh (in the get_syslog_from_qtn argument), that is vulnerable to command injection. This is an instance of CWE-88, "Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')," and is estimated as a CVSS 7.7 ( CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) . This issue affects Quantenna Wi-Fi chipset through version 8.0.0.28 of the latest SDK, and appears to be unpatched at the time of this CVE record's first publishing, though the vendor has released a best practices guide for implementors of this chipset.
{
"affected": [],
"aliases": [
"CVE-2025-32458"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-08T21:15:31Z",
"severity": "HIGH"
},
"details": "The Quantenna Wi-Fi chipset ships with a local control script, router_command.sh (in the get_syslog_from_qtn argument), that is vulnerable to command injection. This is an instance of CWE-88, \"Improper Neutralization of Argument Delimiters in a Command (\u0027Argument Injection\u0027),\" and is estimated as a CVSS 7.7 ( CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) .\nThis issue affects Quantenna Wi-Fi chipset through version 8.0.0.28 of the latest SDK, and appears to be unpatched at the time of this CVE record\u0027s first publishing, though the vendor has released a best practices guide for implementors of this chipset.",
"id": "GHSA-cgwq-jph9-cvc2",
"modified": "2025-06-08T21:30:29Z",
"published": "2025-06-08T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32458"
},
{
"type": "WEB",
"url": "https://community.onsemi.com/s/article/QCS-Quantenna-Wi-Fi-product-support-and-security-best-practices"
},
{
"type": "WEB",
"url": "https://takeonme.org/cves/cve-2025-3460"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CH4V-VXVM-66QF
Vulnerability from github – Published: 2022-05-01 07:21 – Updated: 2025-04-09 03:32Argument injection vulnerability in the Windows Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and Server 2003 SP1 and earlier allows remote user-assisted attackers to execute arbitrary commands via a crafted file with a "/" (slash) character in the filename of the Command Line property, followed by a valid file extension, which causes the command before the slash to be executed, aka "Object Packager Dialogue Spoofing Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2006-4692"
],
"database_specific": {
"cwe_ids": [
"CWE-88",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-10-10T22:07:00Z",
"severity": "MODERATE"
},
"details": "Argument injection vulnerability in the Windows Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and Server 2003 SP1 and earlier allows remote user-assisted attackers to execute arbitrary commands via a crafted file with a \"/\" (slash) character in the filename of the Command Line property, followed by a valid file extension, which causes the command before the slash to be executed, aka \"Object Packager Dialogue Spoofing Vulnerability.\"",
"id": "GHSA-ch4v-vxvm-66qf",
"modified": "2025-04-09T03:32:05Z",
"published": "2022-05-01T07:21:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-4692"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2006/ms06-065"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A496"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval:org.mitre.oval:def:496"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/20717"
},
{
"type": "WEB",
"url": "http://secunia.com/secunia_research/2006-54/advisory"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1017037"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/703936"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/29424"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/448273/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/448696/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/449179/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/20318"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2006/3984"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CHJ3-F7XW-367M
Vulnerability from github – Published: 2022-06-11 00:00 – Updated: 2022-08-22 18:53All versions of package git-promise is vulnerable to Command Injection due to an inappropriate fix of a prior vulnerability in this package. Note: Please note that the vulnerability will not be fixed. The README file was updated with a warning regarding this issue.
Credits
@lirantal for discovering this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "git-promise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-24376"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-17T00:56:05Z",
"nvd_published_at": "2022-06-10T20:15:00Z",
"severity": "HIGH"
},
"details": "All versions of package git-promise is vulnerable to Command Injection due to an inappropriate fix of a prior [vulnerability](https://security.snyk.io/vuln/SNYK-JS-GITPROMISE-567476) in this package. **Note:** Please note that the vulnerability will not be fixed. The README file was updated with a warning regarding this issue. \n### Credits\n @lirantal for discovering this vulnerability.",
"id": "GHSA-chj3-f7xw-367m",
"modified": "2022-08-22T18:53:32Z",
"published": "2022-06-11T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24376"
},
{
"type": "WEB",
"url": "https://github.com/lirantal/git-promise/commit/030e4f993f3b65419d60f7f60e81e0a742b72e77"
},
{
"type": "WEB",
"url": "https://gist.github.com/lirantal/9da1fceb32f5279eb76a5fc1cb9707dd"
},
{
"type": "PACKAGE",
"url": "https://github.com/piuccio/git-promise"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-GITPROMISE-2434310"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "OS Command Injection in git-promise"
}
GHSA-CMM4-PC7P-G834
Vulnerability from github – Published: 2023-12-29 15:30 – Updated: 2025-02-13 18:32Apache OpenOffice documents can contain links that call internal macros with arbitrary arguments. Several URI Schemes are defined for this purpose.
Links can be activated by clicks, or by automatic document events.
The execution of such links must be subject to user approval.
In the affected versions of OpenOffice, approval for certain links is not requested; when activated, such links could therefore result in arbitrary script execution.
This is a corner case of CVE-2022-47502.
{
"affected": [],
"aliases": [
"CVE-2023-47804"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-29T15:15:09Z",
"severity": "HIGH"
},
"details": "Apache OpenOffice documents can contain links that call internal macros with arbitrary arguments. Several URI Schemes are defined for this purpose.\n\nLinks can be activated by clicks, or by automatic document events.\n\nThe execution of such links must be subject to user approval.\n\nIn the affected versions of OpenOffice, approval for certain links is not requested; when activated, such links could therefore result in arbitrary script execution.\n\nThis is a corner case of CVE-2022-47502.",
"id": "GHSA-cmm4-pc7p-g834",
"modified": "2025-02-13T18:32:07Z",
"published": "2023-12-29T15:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47804"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/ygp59swfcy6g46jf8v9s6qpwmxn8fsvb"
},
{
"type": "WEB",
"url": "https://www.openoffice.org/security/cves/CVE-2023-47804.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/01/03/3"
}
],
"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"
}
]
}
GHSA-CQQJ-25GC-9Q2F
Vulnerability from github – Published: 2026-09-26 03:30 – Updated: 2026-09-26 03:30OpenClaw (npm package 'openclaw') versions >= 2026.3.22 and < 2026.8.1 contain an approval-bypass flaw in the exec approval policy: the policy could trust a command-running wrapper without inspecting the command carried in its arguments. After an operator allowlisted or permanently approved a benign wrapper invocation, a later agent turn could substitute an arbitrary inner command and execute it with the OpenClaw process's host privileges without a further approval prompt. Exploitation requires the relevant wrapper to resolve on the host and a prior operator decision allowing that wrapper. Transparent shell carriers and opaque utilities such as process monitors, tracers, namespace tools, and proxy wrappers were affected through related trust-resolution gaps. Fixed in 2026.8.1.
{
"affected": [],
"aliases": [
"CVE-2026-100561"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-26T03:17:02Z",
"severity": "HIGH"
},
"details": "OpenClaw (npm package \u0027openclaw\u0027) versions \u003e= 2026.3.22 and \u003c 2026.8.1 contain an approval-bypass flaw in the exec approval policy: the policy could trust a command-running wrapper without inspecting the command carried in its arguments. After an operator allowlisted or permanently approved a benign wrapper invocation, a later agent turn could substitute an arbitrary inner command and execute it with the OpenClaw process\u0027s host privileges without a further approval prompt. Exploitation requires the relevant wrapper to resolve on the host and a prior operator decision allowing that wrapper. Transparent shell carriers and opaque utilities such as process monitors, tracers, namespace tools, and proxy wrappers were affected through related trust-resolution gaps. Fixed in 2026.8.1.",
"id": "GHSA-cqqj-25gc-9q2f",
"modified": "2026-09-26T03:30:25Z",
"published": "2026-09-26T03:30:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-ghpx-6xwq-2w4w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100561"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-before-2026.8.1-authentication-bypass-via-exec-wrapper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/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:X",
"type": "CVSS_V4"
}
]
}
GHSA-CW25-2P92-7F75
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-30 15:12A vulnerability in the GitHubRepository block of the prefect-github integration in Prefect version 3.6.18 allows an attacker to inject arbitrary git command-line options via the reference field. The reference field is concatenated directly into a git clone command string without proper sanitization, and then parsed by shlex.split(). This enables injection of options such as -c, leading to potential Server-Side Request Forgery (SSRF), credential theft, or remote code execution (RCE). The vulnerability affects both the aget_directory() and get_directory() methods in src/integrations/prefect-github/prefect_github/repository.py. This issue does not affect the GitLab and BitBucket integrations, which use a safer list-based command construction approach.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "prefect"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.6.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-3515"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T15:12:20Z",
"nvd_published_at": "2026-05-24T05:16:39Z",
"severity": "HIGH"
},
"details": "A vulnerability in the `GitHubRepository` block of the `prefect-github` integration in Prefect version 3.6.18 allows an attacker to inject arbitrary git command-line options via the `reference` field. The `reference` field is concatenated directly into a `git clone` command string without proper sanitization, and then parsed by `shlex.split()`. This enables injection of options such as `-c`, leading to potential Server-Side Request Forgery (SSRF), credential theft, or remote code execution (RCE). The vulnerability affects both the `aget_directory()` and `get_directory()` methods in `src/integrations/prefect-github/prefect_github/repository.py`. This issue does not affect the GitLab and BitBucket integrations, which use a safer list-based command construction approach.",
"id": "GHSA-cw25-2p92-7f75",
"modified": "2026-06-30T15:12:20Z",
"published": "2026-05-26T13:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3515"
},
{
"type": "PACKAGE",
"url": "https://github.com/PrefectHQ/prefect"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/f3b048b8-7f4e-45ef-a5a7-cb841c39acde"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Prefect has an Argument Injection issue"
}
GHSA-CW26-7653-2RP5
Vulnerability from github – Published: 2026-05-05 19:53 – Updated: 2026-05-13 14:19Impact
exiftool-vendored starts ExifTool in -stay_open True -@ - mode, where arguments are read from stdin one per line. In affected versions, several caller-supplied strings were interpolated into ExifTool arguments without rejecting line delimiters. A newline or carriage return inside one of those strings could split a single intended argument into multiple ExifTool arguments, allowing argument injection. The fix also rejects NUL bytes as unsafe control characters.
Applications that pass attacker-controlled strings to affected APIs may allow an attacker to make ExifTool read files accessible to the ExifTool process, or write output to attacker-chosen file system paths accessible to that process. No remote code execution has been demonstrated.
The reported write-path issue is caused by unsanitized tag keys. Tag values passed to ExifTool#write are not affected, because WriteTask already encodes whitespace characters in values (e.g. \n -> ) before transmission.
Confirmed affected inputs:
- Tag-name arguments / tag keys — keys of the
tagsobject passed toExifTool#write; entries of theretainoption toExifTool#deleteAllTags; entries of thenumericTagsoption toExifTool#read; thetagnameargument toExifTool#extractBinaryTagand#extractBinaryTagToBuffer. - Filename / path arguments to
ExifTool#write,#read,#readRaw,#deleteAllTags,#rewriteAllTags,#extractBinaryTag,#extractBinaryTagToBuffer, and the binary-extraction convenience methods#extractJpgFromRaw,#extractPreview, and#extractThumbnail.path.resolve()does not strip newlines, so an application that accepts attacker-controlled filenames containing newline characters was vulnerable. - The
imageHashTypeoption toExifTool#read. TypeScript types restrict this to a literal union, but JS callers or callers with weakened type checking could reach the sink.
Applications that only pass hardcoded strings for tag names, options, and filenames are not affected.
Patches
Fixed in v35.19.0. Two layers of defense:
- Per-site input validation. A new
validateTagNamehelper rejects any tag-name string containing characters outside the ExifTool tag grammar (letters, digits,:,-,_, and the ExifTool modifiers*,?,+,#). Applied at every tag-name interpolation site. - Defense-in-depth at the command renderer.
ExifToolTask.renderCommandnow rejects any argument containing\r,\n, or\0before it is sent to the ExifTool process. This catches injection via filename arguments, option values, and any future interpolation site that forgets the per-site validator.
Workarounds
Upgrade to v35.19.0 or later.
If upgrading immediately is not possible, reject untrusted strings containing control characters before passing them to the affected APIs. Conservative guard:
function assertSafeForExifTool(s: string): void {
if (typeof s !== "string" || /[\x00-\x20=<>]/.test(s)) {
throw new Error("Rejected unsafe string for ExifTool");
}
}
Apply to tag names, retain / numericTags entries, binary-extraction tag names, filenames, and the imageHashType option. This is a denylist and is strictly weaker than the library's internal validator; it is sufficient to block the known PoCs but will accept strings that the library itself now rejects.
Resources
- ExifTool
-stay_open/ argument-file documentation: https://exiftool.org/exiftool_pod.html#stay_open-FLAG - ExifTool tag-name reference: https://exiftool.org/TagNames/
- CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') — https://cwe.mitre.org/data/definitions/88.html
Credit
- Reporter: Hank Tam
- Affiliation: Independent
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 35.18.0"
},
"package": {
"ecosystem": "npm",
"name": "exiftool-vendored"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "35.19.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43893"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T19:53:47Z",
"nvd_published_at": "2026-05-11T22:22:14Z",
"severity": "HIGH"
},
"details": "### Impact\n\n`exiftool-vendored` starts ExifTool in `-stay_open True -@ -` mode, where arguments are read from stdin one per line. In affected versions, several caller-supplied strings were interpolated into ExifTool arguments without rejecting line delimiters. A newline or carriage return inside one of those strings could split a single intended argument into multiple ExifTool arguments, allowing argument injection. The fix also rejects NUL bytes as unsafe control characters.\n\nApplications that pass attacker-controlled strings to affected APIs may allow an attacker to make ExifTool read files accessible to the ExifTool process, or write output to attacker-chosen file system paths accessible to that process. No remote code execution has been demonstrated.\n\nThe reported write-path issue is caused by unsanitized tag **keys**. Tag **values** passed to `ExifTool#write` are not affected, because `WriteTask` already encodes whitespace characters in values (e.g. `\\n` -\u003e `\u0026#10;`) before transmission.\n\nConfirmed affected inputs:\n\n- **Tag-name arguments / tag keys** \u2014 keys of the `tags` object passed to `ExifTool#write`; entries of the `retain` option to `ExifTool#deleteAllTags`; entries of the `numericTags` option to `ExifTool#read`; the `tagname` argument to `ExifTool#extractBinaryTag` and `#extractBinaryTagToBuffer`.\n- **Filename / path arguments** to `ExifTool#write`, `#read`, `#readRaw`, `#deleteAllTags`, `#rewriteAllTags`, `#extractBinaryTag`, `#extractBinaryTagToBuffer`, and the binary-extraction convenience methods `#extractJpgFromRaw`, `#extractPreview`, and `#extractThumbnail`. `path.resolve()` does not strip newlines, so an application that accepts attacker-controlled filenames containing newline characters was vulnerable.\n- **The `imageHashType` option** to `ExifTool#read`. TypeScript types restrict this to a literal union, but JS callers or callers with weakened type checking could reach the sink.\n\nApplications that only pass hardcoded strings for tag names, options, and filenames are not affected.\n\n### Patches\n\nFixed in **v35.19.0**. Two layers of defense:\n\n1. **Per-site input validation.** A new `validateTagName` helper rejects any tag-name string containing characters outside the ExifTool tag grammar (letters, digits, `:`, `-`, `_`, and the ExifTool modifiers `*`, `?`, `+`, `#`). Applied at every tag-name interpolation site.\n2. **Defense-in-depth at the command renderer.** `ExifToolTask.renderCommand` now rejects _any_ argument containing `\\r`, `\\n`, or `\\0` before it is sent to the ExifTool process. This catches injection via filename arguments, option values, and any future interpolation site that forgets the per-site validator.\n\n### Workarounds\n\nUpgrade to v35.19.0 or later.\n\nIf upgrading immediately is not possible, reject untrusted strings containing control characters before passing them to the affected APIs. Conservative guard:\n\n```ts\nfunction assertSafeForExifTool(s: string): void {\n if (typeof s !== \"string\" || /[\\x00-\\x20=\u003c\u003e]/.test(s)) {\n throw new Error(\"Rejected unsafe string for ExifTool\");\n }\n}\n```\n\nApply to tag names, `retain` / `numericTags` entries, binary-extraction tag names, filenames, and the `imageHashType` option. This is a denylist and is strictly weaker than the library\u0027s internal validator; it is sufficient to block the known PoCs but will accept strings that the library itself now rejects.\n\n### Resources\n\n- ExifTool `-stay_open` / argument-file documentation: https://exiftool.org/exiftool_pod.html#stay_open-FLAG\n- ExifTool tag-name reference: https://exiftool.org/TagNames/\n- CWE-88: Improper Neutralization of Argument Delimiters in a Command (\u0027Argument Injection\u0027) \u2014 https://cwe.mitre.org/data/definitions/88.html\n\n### Credit\n\n- Reporter: Hank Tam\n- Affiliation: Independent",
"id": "GHSA-cw26-7653-2rp5",
"modified": "2026-05-13T14:19:52Z",
"published": "2026-05-05T19:53:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/photostructure/exiftool-vendored.js/security/advisories/GHSA-cw26-7653-2rp5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43893"
},
{
"type": "WEB",
"url": "https://exiftool.org/TagNames"
},
{
"type": "WEB",
"url": "https://exiftool.org/exiftool_pod.html#stay_open-FLAG"
},
{
"type": "PACKAGE",
"url": "https://github.com/photostructure/exiftool-vendored.js"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "exiftool-vendored vulnerable to argument injection via newline characters in tag names"
}
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.