GHSA-pqg4-j6r4-53mv: OS Command Injection
Impact
quote() emits a { comment } token as # followed by its text, which comments out the rest of the shell line, including the opening quote of any later string token. A line terminator in that later string ends the comment, and the rest of the string is parsed as shell input:
js quote(['echo', 'ok', { comment: 'x' }, 'a\nid;#']); // echo ok #x 'a // id;#'
Passed to sh, bash, dash, ksh, or zsh, this runs id.
parse() emits a comment token for a # in the middle of a word (for example http://example.com/#frag), so callers that combine parse() output with another untrusted string, such as quote(parse(untrustedCommand).concat(untrustedArg)), are affected. The fix for CVE-2026-9277 rejected line terminators in the comment's own text, but not in the tokens after it.
Exploitation requires an attacker-controlled string containing a line terminator that follows a { comment } token in the same quote() call.
Patches
Fixed in v1.11.0: quote() throws a TypeError when a string after a { comment } token contains a line terminator (\n, \r, U+2028, or U+2029).
Workarounds
Drop every token after a { comment } token before calling quote(), or reject line terminators in untrusted strings. Separately, do not append other shell text after quote() output that contains a comment, since the comment swallows it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/shell-quoteto a version that resolves this vulnerability.Fixed in 1.11.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.11.0 - Compensating control
Before calling quote(), drop every token after a { comment } token, or reject untrusted strings containing line terminators (\n, \r, U+2028, or U+2029). Do not append other shell text after quote() output that contains a comment.
Event History
Frequently Asked Questions
What conditions are required for exploitation?
An attacker must be able to control a string containing a line terminator that appears after a { comment } token in the same quote() call. The resulting quoted command must then be passed to a shell such as sh, bash, dash, ksh, or zsh.
Are applications that use parse() also at risk?
They can be. parse() can emit a comment token when a # appears in the middle of a word, so code that combines parse() output with another untrusted string before calling quote() is affected.
What can be done if upgrading is not immediately possible?
Drop every token following a { comment } token before calling quote(). This prevents later attacker-controlled strings from escaping the shell comment through a line terminator.
What versions contain the fix?
The issue is fixed in version 1.11.0. In that version, quote() throws a TypeError if a string after a { comment } token contains \n, \r, U+2028, or U+2029.