This CVE exposes a trust boundary violation in the Ruby LSP VS Code extension (versions before 0.10.4). The extension accepted arbitrary paths for Ruby executables, version managers, and Gemfile locations directly from workspace settings.json. When you open an untrusted repository and click 'trust workspace' — a prompt framed around code you wrote, not environment configuration — you silently grant the repository owner script execution on your machine.
The vulnerability isn't in the Ruby LSP gem itself; it's entirely in the VS Code extension binding. This means the security perimeter is defined by the IDE client, not the language server protocol. The same pattern has appeared in ESLint plugins, pre-commit hooks, and editor formatters: legitimate ergonomic flexibility (custom Ruby versions, project-specific Gemfiles) creates a silent code execution path when untrusted repos are loaded.
What makes this significant is the downstream exposure. A compromised developer workstation has persistent access to VPN tokens, cloud credentials, SSH keys to production, and CI/CD pipelines. The CVSS score captures local impact but collapses the supply chain cascade. Developer machines are high-value targets precisely because they bridge to everything else — yet EPSS scores like 0.00125 treat them as low-exploitability because the model assumes automated wormable attacks, not targeted repository social engineering.
The practical implications: treat workspace trust decisions as environment-compromise decisions, not just code-trust decisions. The 'trust this workspace' prompt should trigger scrutiny of any settings that point to executables or interpreters. Consider verifying that your IDE extensions validate or restrict workspace-supplied paths rather than executing them directly. The fix in 0.10.4 presumably addresses this — verify your extension is updated, and audit similar extensions in your toolchain that accept executable paths from workspace configuration.