shell-quote Input Validation Bypass: Newline Injection in Object Token Operators

Vulnerability Description

The shell-quote library's quote() function implements per-character backslash escaping using the regex /(.)/g, which in JavaScript does not match line terminator characters (\n, \r, U+2028, U+2029). When object tokens with .op fields are passed to quote(), the escaping logic fails to neutralize embedded newlines, allowing them to pass through unescaped. Since POSIX shells treat literal newlines as command separators, this creates a command injection vector. The root cause is incomplete character coverage in the escape routine combined with insufficient validation of object-token structure against the parser's operator whitelist.

Proof-of-Concept Significance

The vulnerability is reachable via two documented API paths: (1) direct construction of malicious object tokens by the caller, and (2) return values from the optional envFn callback that are spliced into parsed results. Neither path requires the parser itself to misbehave—both exploit legitimate API surface. The PoC significance lies in demonstrating that attackers can construct objects with newlines in the .op field that survive quote() and reach the shell, violating the function's contract as a shell-safety boundary. The preconditions are specific (caller must use object tokens) but well-defined and exploitable in real applications handling deserialized or dynamically-generated argument arrays.

Detection Guidance

Code Review Signals: Search for calls to shell-quote's quote() function where the input array may contain objects (not just strings), particularly when those objects originate from external deserialization, environment variable expansion, or untrusted callbacks. Flag usage of the envFn parameter with data sources that may be attacker-influenced.

Runtime Detection: Monitor for unexpected shell invocations or command sequences that follow newline characters in argument strings passed to shell execution APIs (e.g., child_process.exec(), os.system()). Log and alert on instances where quote() output contains unescaped line terminators.

Static Analysis: SAST tools should flag object token construction in user-controlled code paths feeding into quote() and flag any .op field assignments from external sources.

Mitigation Steps

Immediate Actions:

• Upgrade shell-quote to a patched version (≥ CVE-2026-9277 fix) that correctly escapes all line terminators in object .op fields.
• Audit all callers of quote() to confirm they do not pass object tokens with attacker-controlled .op values.
• If envFn is used, ensure the callback validates returned objects against a strict whitelist of allowed operators.
• For defense-in-depth: prefer using shell argument arrays directly (e.g., child_process.execFile()) over shell-string construction wherever possible.

Configuration & Workarounds:

• Disable dynamic object token construction; only use quote() with string tokens when possible.
• Implement input validation middleware that rejects object tokens with line terminators in .op before calling quote().
• Use allowlists for .op values matching the parser's fixed operator set (|, &, ;, etc.).

Risk Assessment

Likelihood of Exploitation: Moderate to High. The vulnerability requires specific architectural choices (passing object tokens to quote()) but those patterns are documented and plausible in applications deserializing argument arrays or using dynamic shell construction. npm package popularity of shell-quote increases the surface area.

Threat Actor Interest: High. Command injection vulnerabilities in widely-used shell-escaping libraries are high-value targets. Attackers may target applications that accept structured input (JSON, serialized data) and reconstruct shell commands dynamically.

In-the-Wild Risk: The narrow precondition (object tokens, not plain strings) may limit mass exploitation but does not eliminate it. Targeted exploitation against applications using envFn callbacks or deserializing command structures is realistic and likely already occurring.