CVE-2026-102422 in shell-quote
Summary
by MITRE • 09/29/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/29/2026
The shell-quote library contains a critical command injection vulnerability within its quote function that allows an attacker to execute arbitrary commands by exploiting how the library handles inline comments and subsequent string tokens. The core issue arises from the specific behavior of the { comment } token, which is emitted as a hash symbol followed by text intended to act as a line comment in shell environments. In standard POSIX-compliant shells such as sh, bash, dash, ksh, and zsh, any characters following a hash on the same logical line are ignored until a newline character terminates that comment context. The vulnerability occurs when this mechanism interacts with subsequent string tokens that contain literal line terminators, including newlines (\n), carriage returns (\r), Unicode line separator (U+2028), and paragraph separator (U+2029).
When the quote function processes a sequence of arguments where one argument is designated as a comment token followed by another untrusted string containing a line terminator, it fails to properly escape or neutralize that terminator. Consequently, the hash symbol from the previous token comments out the opening quotes and subsequent content of the next token up until the point where the line terminator appears. Once the newline occurs, the shell interprets this as the end of the comment block, causing all remaining characters in that string to be parsed as active shell input rather than literal data. This effectively breaks the quoting mechanism, allowing an attacker who controls any part of the argument list after a comment token to inject and execute arbitrary commands by embedding a line break followed by malicious payload code.
This flaw is particularly dangerous because it can be triggered through common usage patterns where developers combine parsed output with additional untrusted arguments. For instance, if a developer uses parse() on an untrusted command string and then concatenates that result with another untrusted argument before passing them to quote(), the resulting shell invocation may inadvertently contain comment tokens followed by user-controlled strings with embedded newlines. A concrete example of this exploitation involves constructing an input where a later token contains a newline character immediately preceding a command like id;#. In such cases, the initial part of the string is commented out, but the portion after the newline executes directly in the shell environment, leading to remote code execution if the vulnerable application runs with elevated privileges or processes sensitive data.
The technical root cause lies in the incomplete fix applied for CVE-2026-9277, which previously addressed line terminators within the comment text itself but neglected to validate them in subsequent tokens that follow a comment marker. This oversight means that while direct injection via newlines inside comments was mitigated, indirect injection through adjacent strings remained possible. The vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and is relevant to ATT&CK technique T1059 Command and Scripting Interpreter, specifically regarding the abuse of shell features for command execution. It highlights the complexity of safely handling untrusted input when interfacing with operating system shells, where context switching between quoted strings and comment states can be exploited if not strictly enforced by the wrapper library.
To mitigate this risk, users must upgrade to version 1.11.0 or later of the shell-quote library, which implements a strict validation check that throws a TypeError whenever any string following a { comment } token contains a line terminator. This defensive programming approach prevents the malformed input from reaching the shell interpreter entirely, thereby neutralizing the injection vector. For applications unable to upgrade immediately, developers should avoid using inline comments in argument lists derived from untrusted sources and ensure that all user-supplied strings are sanitized for control characters before being passed to quoting functions. Additionally, adopting parameterized execution methods or avoiding shell interpretation altogether by invoking executables directly with arrays of arguments can provide a more robust defense against command injection vulnerabilities of this nature.