--- title: "GHSA-w7jw-789q-3m8p: shell-quote quote() does not escape newlines in object .op values" description: "Critical severity. shell-quote quote() does not escape newlines in object .op values. Affects shell-quote; fixed in 1.8.4." url: https://inlinr.com/advisories/GHSA-w7jw-789q-3m8p lang: en --- [Packages](https://inlinr.com/packages) / [shell-quote](https://inlinr.com/packages/shell-quote) / [Security](https://inlinr.com/packages/shell-quote/security) Critical Vulnerability GHSA-w7jw-789q-3m8p CVE-2026-9277 Published 9 Jun 2026 # shell-quote quote() does not escape newlines in object .op values Your version Affected releases · [shell-quote](https://inlinr.com/packages/shell-quote) - 1.x 1.1.0 – 1.8.3 Fixed in 1.8.4 On 1.x, the newest line: ``` npm install shell-quote@1.8.4 ``` Every release on a timeline 1. Not affected 0.0.0 – 1.0.0 5 releases 2. Affected 1.1.0 – 1.8.3 24 releases 3. Fixed 1.8.4 – 1.12.0 5 releases, latest 34 stable releases of shell-quote, oldest to newest. ## What happens Summary `shell-quote`'s `quote()` function did not validate object-token inputs against the operator model used by `parse()`. The `.op` field was backslash-escaped character by character using `/(.)/g`, which in JavaScript does not match line terminators (`\n`, `\r`, U+2028, U+2029). A line terminator in `.op` therefore passed through unescaped into the output; POSIX shells treat a literal `\n` as a command separator, so any content after it would execute as a second command. The vulnerable code path is reachable in two ways. Neither requires the parser to misbehave — `parse()` only emits ops from a fixed control set — but both are documented API surface: 1. **Direct construction.** A caller builds `{ op: '...\n...' }` from external input (e.g. a deserialized argument array) and passes it to `quote()`. 2. **`envFn` return.** `parse(cmd, envFn)` is documented to splice the return value of `envFn` into the result array when it is an object. An attacker-influenced data source consulted by `envFn` can introduce an object token whose `.op` reaches `quote()`. Impact Shell command injection in callers that pass object tokens with attacker-influenced `.op` values to `quote()` and then hand the result to a shell. The preconditions are narrower than ordinary string injection — they require the caller to feed object tokens into `quote()` — but object tokens are a public, documented part of the API surface, and `quote()` is intended to be a shell-safety boundary. PoC ``` const { parse, quote } = require('shell-quote'); // Direct construction quote([{ op: ';\nid' }]); // → "\;\n\\i\\d" ← literal newline; second line executes as a command // Via parse() with an envFn returning attacker-shaped objects const tokens = parse('echo $X', () => ({ op: ';\nid' })); require('child_process').execSync(quote(tokens), { shell: true }); // Executes `id` after `echo \;`. ``` Confirmed under `sh`, `bash`, `dash`, and `zsh`. Patch Fixed by replacing the per-character escape with strict shape validation in `quote()`. The object-token branch now: - **`{ op }`** — `.op` must be a string from the same allowlist the parser emits (`||`, `&&`, `;;`, `|&`, `<(`, `<<<`, `>>`, `>&`, `<&`, `&`, `;`, `(`, `)`, `|`, `<`, `>`). Anything else throws `TypeError`. This is the direct fix for the reported issue and removes the entire class of `.op` injection. - **`{ op: 'glob', pattern }`** — `.pattern` must be a string with no line terminators. Glob metacharacters (`*`, `?`, `[`, `]`, `{`, `}`, `,`) pass through; all other shell-special characters are backslash-escaped. (Previously the pattern field was discarded entirely and the literal string `\g\l\o\b` was emitted — a latent bug, not security-relevant.) - **`{ comment }`** — `.comment` must be a string with no line terminators (line terminators would end the shell comment and resume command parsing — same injection shape). - **Any other object shape** — `TypeError`. The fix is allowlist-based rather than a targeted regex tweak, so it closes the reported vector and forecloses adjacent ones (U+2028 / U+2029 line separators in `.op`, line terminators in comments, unknown-shape objects coerced through `.replace`). Workarounds Prior to upgrading, callers that build object tokens from untrusted input should validate `.op` against the parser's operator set themselves, and never construct `{ op }` from attacker-controlled strings. Credits Reported by Akshat Sinha ## How it is exploited Exploitable over the network, with no account and no action from a user. - **Confidentiality**: high - **Integrity**: high - **Availability**: high CVSS:3.1/​AV:N/​AC:H/​PR:N/​UI:N/​S:U/​C:H/​I:H/​A:H ## References - [Reference](https://github.com/ljharb/shell-quote/security/advisories/GHSA-w7jw-789q-3m8p "https://github.com/ljharb/shell-quote/security/advisories/GHSA-w7jw-789q-3m8p") github.com/ljharb/shell-quote/security/advisori… - [NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-9277 "https://nvd.nist.gov/vuln/detail/CVE-2026-9277") nvd.nist.gov/vuln/detail/CVE-2026-9277 - [Fix commit](https://github.com/ljharb/shell-quote/commit/1518179 "https://github.com/ljharb/shell-quote/commit/1518179") 1518179 - [Package](https://github.com/ljharb/shell-quote "https://github.com/ljharb/shell-quote") github.com/ljharb/shell-quote - [Reference](https://www.npmjs.com/package/shell-quote "https://www.npmjs.com/package/shell-quote") npmjs.com/package/shell-quote - [Reference](http://www.openwall.com/lists/oss-security/2026/05/23/2 "http://www.openwall.com/lists/oss-security/2026/05/23/2") openwall.com/lists/oss-security/2026/05/23/2