https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 03:33:55 +0000 https://vulnerability.circl.lu/vuln/cve-2026-9277 <p><strong>Affected:</strong> shell-quote, Red Hat Cryostat 4 on RHEL 9, Red Hat Cluster Observability Operator 1.5.0, Red Hat Ansible Automation Platform 2.1, Red Hat Developer Hub 1.10, Red Hat Developer Hub 1.9, Red Hat Discovery 2, Red Hat Migration Toolkit 1.8, Red Hat OpenShift Container Platform 4.14, Red Hat OpenShift Container Platform 4.15 and 39 more</p> <p>shell-quote&#39;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 newline as a command separator, so any content after it would execute as a second command. The vulnerable code path is reachable in two ways: (1) direct construction of `{ op: &#39;...\n...&#39; }` from external input, and (2) via `parse(cmd, envFn)` when `envFn` returns object tokens whose `.op` is attacker-influenced. Both are documented API surface. Fixed by replacing the per-character escape with strict shape validation: `.op` must match the parser&#39;s control-operator allowlist; `{ op: &#39;glob&#39;, pattern }` validates `pattern` and forbids line terminators; `{ comment }` validates `comment` and forbids line terminators; any other object shape throws `TypeError`.</p> <p><strong>Affected:</strong> shell-quote, Red Hat Cryostat 4 on RHEL 9, Red Hat Cluster Observability Operator 1.5.0, Red Hat Ansible Automation Platform 2.1, Red Hat Developer Hub 1.10, Red Hat Developer Hub 1.9, Red Hat Discovery 2, Red Hat Migration Toolkit 1.8, Red Hat OpenShift Container Platform 4.14, Red Hat OpenShift Container Platform 4.15 and 39 more</p> <p>shell-quote&#39;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 newline as a command separator, so any content after it would execute as a second command. The vulnerable code path is reachable in two ways: (1) direct construction of `{ op: &#39;...\n...&#39; }` from external input, and (2) via `parse(cmd, envFn)` when `envFn` returns object tokens whose `.op` is attacker-influenced. Both are documented API surface. Fixed by replacing the per-character escape with strict shape validation: `.op` must match the parser&#39;s control-operator allowlist; `{ op: &#39;glob&#39;, pattern }` validates `pattern` and forbids line terminators; `{ comment }` validates `comment` and forbids line terminators; any other object shape throws `TypeError`.</p> https://vulnerability.circl.lu/vuln/cve-2026-9277