CVE-2026-102422: shell-quote `quote()` command injection via a line terminator in a token after a `{ comment }` token
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.
Other sources
shell-quote's quote() function 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 (\n, \r, U+2028, U+2029) in that later string therefore ends the comment, and the rest of the string is parsed as shell input: quote(['echo', 'ok', { comment: 'x' }, 'a\nid;#']) runs id in sh, bash, dash, ksh and zsh. 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. Fixed in 1.11.0: quote() throws a TypeError when a string after a { comment } token contains a line terminator.
— NVD
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
shell-quoteto 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 line terminators (\n, \r, U+2028, U+2029) in untrusted strings. Do not append other shell text after quote() output that contains a comment.
Event History
Frequently Asked Questions
What application patterns are exposed?
Applications are exposed when they pass shell-quote quote() output to a shell and build the token list with a { comment } token followed by an attacker-controlled string. A particularly relevant pattern is quote(parse(untrustedCommand).concat(untrustedArg)), because parse() can produce a comment token from a # occurring mid-word, such as in a URL fragment.
What does an attacker need to exploit this?
An attacker needs control of a string token placed after a { comment } token and must be able to include a line terminator: \n, \r, U+2028, or U+2029. The content after that terminator can then be interpreted as shell input.
Which shells are known to be affected?
The described payload executes in sh, bash, dash, ksh, and zsh. The issue arises because the emitted # comments out the later opening quote until a line terminator ends the comment.
How can this be remediated or mitigated?
Upgrade shell-quote to version 1.11.0, where quote() throws a TypeError if a string after a { comment } token contains a line terminator. If upgrading is not immediately possible, do not allow line terminators in any string token following a comment token, and avoid combining parse() output from untrusted commands with untrusted arguments.
How can I identify potentially affected code?
Review quote() call sites for arrays containing { comment: ... } followed by strings influenced by untrusted input. Also search for flows that feed parse() output into quote(), especially where the parsed command or appended arguments are untrusted and may contain # or line terminators.