Code highlighting extension for Cursor AI used for $500k theft

Original Article ↗ Hacker News Discussion ↗

Supply-chain risk and dev setups

  • Many commenters see this as yet another supply-chain attack and describe hardening their workflows: per‑project VMs/containers, minimal host installs, Nix, Flatpak, or LXC.
  • There’s frustration that modern stacks require opaque binaries and network access just to build, making true from-source, offline bootstrapping rare.
  • Some share simple container workflows (e.g., one container per project with only that folder mounted), and distrust “devcontainers” that expose too much of the host (.ssh, full FS).

VS Code, Cursor, and Open VSX responsibilities

  • Debate centers on who bears responsibility: Cursor (a commercial product), Open VSX (volunteer‑run registry), or the user.
  • One side: Cursor is a high‑funding company effectively outsourcing a critical security component to under‑resourced volunteers; they should fund or provide hardened infrastructure and vetting.
  • The other side: Cursor merely exposes a third‑party registry; users choosing random extensions must accept the risk, similar to package managers.
  • Microsoft’s tweet about blocking the malicious extension “in 2 seconds” is seen by some as marketing; others note VS Code’s marketplace still lets many malware extensions through.

Extension security model and sandboxing

  • Multiple people were surprised to learn that VS Code/Cursor extensions are not sandboxed and inherit full user permissions: filesystem, network, and ability to spawn processes (e.g., PowerShell).
  • Comparisons are made to browser extensions (sandboxed) vs Electron apps (browser UI, fewer OS protections).
  • Several argue editors should implement permission systems and sandboxing (Docker, WASM, or OS sandboxes); others claim perfect sandboxing of arbitrary code is unrealistic.

Crypto storage and user behavior

  • Strong criticism of keeping ~$500k of crypto on a general dev machine; many argue such amounts should live on hardware wallets or isolated “bank‑like” devices.
  • Counterpoint: in practice, few people can realistically audit all software they run, and modern computing makes true vigilance hard.

Mitigation strategies proposed

  • Use hardware wallets and testnets; segregate “money machines” from dev machines.
  • Restrict or whitelist extensions, pin versions (e.g., via Nix), and monitor network traffic.
  • Run IDEs in containers/VMs with limited filesystem access; keep sensitive data in separate encrypted locations.