NodeJS/shell-quote/1.4.2

Potential Command Injection in shell-quote

Affected versions of shell-quote do not properly escape command line arguments, which may result in command injection if the library is used to escape user input destined for use as command line arguments.

Proof of Concept:

The following characters are not escaped properly: >,;,{,}

Bash has a neat but not well known feature known as Bash Brace Expansion, wherein a sub-command can be executed without spaces by running it between a set of {} and using the , instead of to seperate arguments. Because of this, full command injection is possible even though it was initially thought to be impossible.

   const quote = require('shell-quote').quote;
   console.log(quote(['a;{echo,test,123,234}']));
   // Actual                    "a;{echo,test,123,234}"
   // Expected                  "a\;\{echo,test,123,234\}"
   // Functional Equivalent     "a; echo 'test' '123' '1234'"

Recommendation

Update to version 1.6.1 or later.

shell-quote quote() does not escape newlines in object .op values

Summary

shell-quote's quote() function did not validate object-token inputs against the operator model used by parse(). The .op field was backslash-escaped character by character using /(.)/g, which in JavaScript does not match line terminators (\n, \r, U+2028, U+2029). A line terminator in .op therefore passed through unescaped into the output; POSIX shells treat a literal \n as a command separator, so any content after it would execute as a second command.

The vulnerable code path is reachable in two ways. Neither requires the parser to misbehave — parse() only emits ops from a fixed control set — but both are documented API surface:

1. Direct construction. A caller builds { op: '...\n...' } from external input (e.g. a deserialized argument array) and passes it to quote().
2. envFn return. parse(cmd, envFn) is documented to splice the return value of envFn into the result array when it is an object. An attacker-influenced data source consulted by envFn can introduce an object token whose .op reaches quote().

Impact

Shell command injection in callers that pass object tokens with attacker-influenced .op values to quote() and then hand the result to a shell. The preconditions are narrower than ordinary string injection — they require the caller to feed object tokens into quote() — but object tokens are a public, documented part of the API surface, and quote() is intended to be a shell-safety boundary.

PoC

const { parse, quote } = require('shell-quote');

// Direct construction
quote([{ op: ';\nid' }]);
// → "\;\n\\i\\d"  ← literal newline; second line executes as a command

// Via parse() with an envFn returning attacker-shaped objects
const tokens = parse('echo $X', () => ({ op: ';\nid' }));
require('child_process').execSync(quote(tokens), { shell: true });
// Executes `id` after `echo \;`.

Confirmed under sh, bash, dash, and zsh.

Patch

Fixed by replacing the per-character escape with strict shape validation in quote(). The object-token branch now:

• { op } — .op must be a string from the same allowlist the parser emits (||, &&, ;;, |&, <(, <<<, >>, >&, <&, &, ;, (, ), |, <, >). Anything else throws TypeError. This is the direct fix for the reported issue and removes the entire class of .op injection.
• { op: 'glob', pattern } — .pattern must be a string with no line terminators. Glob metacharacters (*, ?, [, ], {, }, ,) pass through; all other shell-special characters are backslash-escaped. (Previously the pattern field was discarded entirely and the literal string \g\l\o\b was emitted — a latent bug, not security-relevant.)
• { comment } — .comment must be a string with no line terminators (line terminators would end the shell comment and resume command parsing — same injection shape).
• Any other object shape — TypeError.

The fix is allowlist-based rather than a targeted regex tweak, so it closes the reported vector and forecloses adjacent ones (U+2028 / U+2029 line separators in .op, line terminators in comments, unknown-shape objects coerced through .replace).

Workarounds

Prior to upgrading, callers that build object tokens from untrusted input should validate .op against the parser's operator set themselves, and never construct { op } from attacker-controlled strings.

Credits

Reported by Akshat Sinha

Potential Command Injection

The npm module shell-quote cannot correctly escape > and < operator used for redirection in shell. I'm wondering if this might be possible vulnerability for many application which depends on shell-quote.

For example:

const quote = require('shell-quote').quote; console.log(quote(['foo>bar']));

will print foo>bar, where foo\>bar is desirable.

This module is downloaded more than 1M times per month and many other modules are depending on this. If an application is escaping command-line args with this module, they might be vulnerable from malicious user input.

For example: ``` var sq = require('../tests/get/shell-quote-1.6.0'); var exec = require('child_process').exec;

var pattern = process.argv[2];

command = sq.quote(['grep', pattern])); exec('cat file | ' + command, function ( err, stdout, stderr) { console.log(command, stdout);
}); ``` will be vulnerable when user input something like pattern = ':</etc/passwd', which causes the content of /etc/passwd to be leaked.

Internally, (Jon Lamendola, Nick Starke, Jacob Waddell) found that the ;, {, and } characters weren't escaped properly either. This allows for full command injection. A malicious user could input 'a;{echo,test,123,234}' to execute echo fully.