Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-29T04:17:55.707Z",
  "pubdate": "2026-09-29T04:17:55.707Z",
  "executiveSummary": "The shell-quote library is vulnerable to a command injection flaw resulting from improper handling of comment tokens within the quote() function. This vulnerability allows an attacker to break out of the intended command context and execute arbitrary shell commands by leveraging line terminators in subsequent string tokens.\nThe impact includes arbitrary code execution with the privileges of the underlying shell process. This affects all systems utilizing shell-quote versions prior to 1.11.0. The vulnerability is triggered when untrusted input, particularly strings containing malicious newline sequences combined with comment tokens, is processed through the quote() function.\nThe risk is severe as it allows attackers to bypass intended argument escaping mechanisms. Exploitation does not require prior authentication, provided the attacker can influence the input arguments processed by the application. This flaw persists even after the partial fix for CVE-2026-9277, necessitating an upgrade to version 1.11.0 to enforce strict validation on tokens following comment blocks.",
  "technicalDetails": "The vulnerability resides in the interaction between the quote() function's comment token handling and the shell's interpretation of line terminators. In shell-quote, a { comment: '...' } token is serialized as a '#' character followed by the specified text. Because shell syntax treats the '#' character as the initiation of a comment that persists until the end of the line, any content following the comment token is ignored by the shell parser.\nThe root cause is an insufficient validation mechanism within the quote() function. While CVE-2026-9277 addressed line terminators within the comment string itself, it failed to sanitize or validate subsequent tokens. When a developer constructs a command array using a combination of parsed tokens—such as calling quote(parse(untrustedCommand).concat(untrustedArg))—the logic permits an attacker to inject a line terminator in a token that follows a comment token.\nThe attack flow follows a specific sequence: 1) The attacker provides an input that results in a '{ comment: 'x' }' object being generated during the parse() or construction phase. 2) The attacker follows this comment token with a string containing a line terminator (e.g., '\\n') and an malicious shell command (e.g., 'id'). 3) When quote() processes this array, the comment token injects a '#' into the shell line. 4) The shell parser treats everything until the newline as a comment. 5) Upon reaching the newline, the shell terminates the comment and begins interpreting the subsequent string as a new shell command. 6) The injected command is then executed in the context of the calling shell (sh, bash, dash, ksh, or zsh).\nThis vulnerability effectively renders the quote() function ineffective as a security control for sanitizing user-supplied input. By manipulating the token structure, an attacker can escape the shell-escaping logic, leading to full command injection. This is particularly dangerous when the library is used in conjunction with 'parse()' or when handling untrusted data from multiple sources that might be concatenated into the command argument list before final serialization."
}