CVE-2026-102422: shell-quote `quote()` command injection via a line terminator in a token after a `{ comment }` token

Published Sep 29, 2026
·
Updated

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.

Affected Software

1 affected component
npm/shell-quote<1.11.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade shell-quote to a version that resolves this vulnerability.

    Fixed in 1.11.0

Event History

Sep 29, 2026
CVE Published
via MITRE·03:47 AM
Data Sourced
via MITRE·03:47 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·04:17 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

5

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203