Threat actors expand abuse of Microsoft Visual Studio Code

Original Article ↗ Hacker News Discussion ↗

Why VS Code Became (Perceived) Default vs Eclipse

  • Many see VS Code as “good enough everywhere”: free, MIT-licensed, cross‑platform, strong extension ecosystem, good default UX, solid fuzzy file navigation, and language‑neutral via LSP.
  • It runs in the browser and is embedded in major cloud consoles, further normalizing it.
  • Eclipse is remembered as slow, memory‑hungry, janky, and strongly Java‑centric; plugins for other languages often lagged or were brittle.
  • In the Java world, IntelliJ/other JetBrains IDEs are widely seen as Eclipse’s real replacement; for many, JetBrains tools are superior to both Eclipse and VS Code, but cost and licensing matter.

Performance, Editor Types, and Ecosystem

  • Split views: some call VS Code “dog slow” (especially with many extensions or large C/C++ projects); others say startup is seconds, which is irrelevant if the IDE stays open all day.
  • Several prefer neovim/Emacs (often via LazyVim etc.) for sub‑50ms startup and deep scriptability; others don’t want TUI editors.
  • Electron itself is criticized as a resource hog and large attack surface; some explicitly trust JVM‑based IDEs more than HTML/JS stacks.

Tool Standardization vs Developer Choice

  • Some view being forced onto a specific editor as a red flag and a sign of fungible engineers.
  • Others argue standard setups reduce IT/support cost, ease pairing/debugging, and avoid “works on my machine”; devcontainers/remote VMs are popular for consistent environments.

Security, Workspace Trust, and Auto‑Execution

  • Core concern: merely opening and “trusting” a folder in VS Code can lead to automatic processing of tasks.json and other config, enabling arbitrary command execution.
  • Many compare this to USB autorun or macro‑enabled Office documents; users are expected to make correct security choices in the middle of their workflow, which they often won’t.
  • The “Do you trust the authors of these files?” dialog is seen by critics as vague, over‑broad (“may execute files”), and easy to click through like cookie banners; it doesn’t specify what will actually run.
  • A VS Code team member explains:
    • Workspace trust is the main defense; restricted mode intentionally degrades features (language servers, debugging, automatic tasks) to avoid code execution.
    • There are many execution paths (build tools, test collectors, language servers, LLM agents), so it’s impossible to list them all or know ahead of time which will fire.
  • Suggestions from commenters:
    • Default to restricted mode and only prompt when a specific action needs trust.
    • Make warnings more concrete (which files/scripts, what they can do).
    • Add scanning or heuristics to highlight suspicious tasks and scripts.

Broader Risk Model and Possible Mitigations

  • Several note this isn’t unique to VS Code: build systems (Make, Gradle, Maven, npm, etc.) and editor plugins routinely run project code; any clone‑and‑build workflow is dangerous.
  • Some advocate containers/VMs as the default for development to shield host machines, though others point out that compromised projects can still backdoor artifacts, scripts, and credentials inside the container.
  • Overall sentiment: convenience features and rich IDE behavior have again eroded safety, and the current model places too much security responsibility on end‑users at the wrong time.