Open VSX: 77 malicious extensions impersonated developer tools

Researchers found 77 evil-twin extensions in the Open VSX registry that imitated the names, descriptions and functions of popular add-ons for VS Code-compatible editors. Once installed, they collected host, user, operating-system, path and development-environment information and sent it to campaign infrastructure.

An editor extension is not merely a colour theme. It may read an open project, execute Node.js code, observe commands, use the network and see secrets available to the IDE process. A marketplace compromise or convincing publisher impersonation is therefore a supply-chain attack with the developer’s permission set as its blast radius.

Campaign mechanics

Operators exploited similar names and icons, expecting installation from search suggestions or project instructions. Some add-ons kept the advertised feature working to avoid suspicion. Malicious JavaScript ran in the background, profiled the system and initiated outbound connections.

Open VSX is used by VSCodium and many forks and cloud environments. It is not the Microsoft Marketplace: publisher and extension identities may differ between registries. The same visual title does not establish the same package identity.

Earlier investigations, including the Count Dooku campaign analysis, show that operators can publish multiple variants, use extension dependencies and updates, and quickly rebuild removed listings. Removing a package from the catalogue does not automatically uninstall it from workstations, and credentials already collected remain exposed.

What may be compromised

Workstations holding SSH keys, cloud credentials, npm or PyPI tokens, private-repository access and production tooling face the greatest risk. Repository and directory names may be enough to select targets. If an extension reads environment variables or configuration files, reconnaissance can become account takeover and malicious package publication.

An organisation cannot simply ask users whether they recognise an add-on’s display name. Inventory must collect the full publisher.extension identifier, version, installation source, package hash and first-seen timestamp.

DevSecOps response plan

1. Export extension inventories from every editor and compare them with an approved catalogue, including the publisher identifier.
2. Remove suspicious add-ons after preserving the VSIX package, local logs and network telemetry for analysis.
3. Rotate keys present on the workstation since installation, especially SSH, Git, cloud, package-registry and CI/CD credentials.
4. Search DNS, proxy and EDR data for new domains contacted by editor processes and child Node.js processes.
5. Block installation outside a corporate allowlist or distribute extensions through a controlled internal registry.
6. Verify signatures, hashes, source repositories and publisher history; download volume is not proof of trust.
7. Run development environments without durable secrets and issue short-lived credentials for specific operations.

Inventory must extend beyond laptops

IDE extensions also persist in development containers, remote workspaces, golden images and caches used to recreate environments. Removing an add-on from one workstation is insufficient when the same VSIX remains in a devcontainer template or an extension directory mounted into future sessions. Indicators therefore have to be matched against workstation-build artefacts as well as currently signed-in users.

Telemetry should connect an extension hash with child processes of the editor. A legitimate language add-on may launch a compiler, but it rarely needs to read several key directories, enumerate cloud credentials and contact a newly registered domain. Establishing a baseline per extension identifier makes behavioural changes after an update visible. For critical teams, updates should pass through quarantine and a permission-difference review instead of deploying automatically to every workstation.

Primary facts versus analysis

Public reporting confirms the discovery and removal of 77 listings and data collection by malicious code. An installation does not prove theft of every secret, and the precise reach depends on extension version and process permissions.

Breachroad’s conclusion is that an IDE marketplace distributes executable code and needs the same controls as npm or a container registry. Developer security training should cover extension verification, while an IT security audit can assess allowlisting, EDR coverage, secret handling and workstation recovery.