Cyberwarzone

VSCode fork extension attack: hijacked recommendations

—

by

Peter Chofield
in
Summarize with:



VSCode fork extension attack lets threat actors claim unowned OpenVSX namespaces for extensions that AI-powered forks like Cursor, Windsurf, Google Antigravity, and Trae still recommend by default.

Why it matters now

The VSCode fork extension attack abuses developer trust: a click on a familiar recommendation can install an attacker’s package with IDE-level permissions, workspace access, and credential reach. Keep this keyphrase in mind because it defines the current supply-chain gap.

Key facts at a glance

  • Issue: Forked VSCode IDEs inherit recommendation lists that point to Microsoft’s marketplace; the same extensions often do not exist in OpenVSX.
  • Exposure: An attacker can register the empty OpenVSX namespace (e.g., ms-azure-devops.azure-pipelines) and ship malware that shows up as a trusted recommendation.
  • Affected forks: Cursor, Windsurf, Google Antigravity, Trae; all rely on OpenVSX instead of Microsoft’s marketplace.
  • Timeline: Koi reported the gap in late Nov 2025; Cursor fixed Dec 1; Google removed 13 suggestions on Dec 26 and marked fixed Jan 1; Windsurf has not responded yet.
  • Current status: Koi preemptively claimed several namespaces with harmless placeholders; no malicious exploitation observed so far.
  • Source: BleepingComputer plus Koi research.

How the VSCode fork extension attack works

Forked IDEs keep Microsoft’s hardcoded recommendations even though they cannot use the Visual Studio Marketplace. When OpenVSX lacks those namespaces, anyone can register them. A malicious publisher can then appear as the “official” suggestion when the IDE prompts an install.

Recommendation triggers 2025-11-30

IDE suggests an extension after detecting a file like azure-pipelines.yaml or software like PostgreSQL.

Namespace hijack 2025-12-05

Attacker registers the unclaimed OpenVSX namespace referenced by the recommendation.

Malicious publish 2025-12-06

Attacker uploads a trojaned extension under the hijacked name.

One-click install 2025-12-07

Developer accepts the trusted-looking prompt and grants workspace/system access.

Patch or removal 2025-12-26

Vendors remove the recommendation or replace it with a vetted namespace.

The prompts look routine, so social engineering cost is near zero. Because these forks are marketed as AI copilots, teams often grant them wide filesystem and network permissions, magnifying blast radius.

How to harden VSCode forks right now

  • Disable auto-accept: Block automatic installs from recommendations; require explicit review of publisher, version, and registry.
  • Pin an allowlist: Maintain a short list of approved OpenVSX publishers and lock extensions to hashes.
  • Mirror critical extensions: Host your own vetted OpenVSX mirror for CI and developer workstations.
  • Audit prompts: Log every recommended extension event and alert when the namespace is newly created.
  • Train on lookalikes: Teach developers that “recommended” does not mean “official”; compare to typosquats in npm and PyPI.

Error: Both labels and values are required.
Error: Both labels and values are required.
Error: Both labels and values are required.

Similar supply-chain themes showed up in the GlassWorm macOS supply-chain wave and the Shai-Hulud npm-driven Trust Wallet drain, where trusted delivery channels were turned hostile.

Sources and verification

We corroborated the unclaimed namespaces list and the vendor remediation dates against the Koi disclosure and the BleepingComputer report.

Detection signals to monitor

  • IDE prompts for extensions whose namespaces were created within the last 14 days.
  • Recommendations that point to publishers without corporate verification or with zero download history.
  • Unsigned or hash-changing updates to recommended extensions on OpenVSX mirrors.
  • Unexpected outbound connections from the IDE process after a recommendation is accepted.
  • File-system writes outside the workspace (SSH keys, cloud CLI configs, browser profiles).

Push high-signal alerts to paging, not just chat, because the VSCode fork extension attack triggers through user clicks, not exploits.

24-hour actions for engineering teams

  • Stop-gap: block new OpenVSX publishers unless on your allowlist; freeze auto-installs.
  • Reclaim risk: preemptively register the specific namespaces your org uses (Azure Pipelines, PostgreSQL, Heroku, Cake build).
  • Integrity: pin extensions by hash in devcontainer.json or internal policy files.
  • Visibility: log all recommendation prompts and extensions installed via IDE UI.
  • Awareness: send a short PSIRT note to developers describing the VSCode fork extension attack and how to decline suspicious prompts.

These moves close the social-engineering gap while vendors finish upstream fixes.

FAQ

  • Is this a CVE? Not yet; it is a design/ops gap in how forks inherit recommendations.
  • Did anyone weaponize it? No public evidence; Koi parked the risky namespaces first.
  • Should we stop using these IDE forks? No, but enforce extension allowlists and hash pinning until upstreams finish registry hygiene.
  • Does Microsoft VSCode have the same risk? Not in the same way; it uses the Visual Studio Marketplace where these namespaces are already occupied, though typosquats remain a concern.