Why did 77 Evil Twin Open VSX extensions collect repo data?

TL;DR: Copying real VS Code Marketplace names and namespaces let 77 counterfeit Open VSX extensions pass as trusted packages, according to Manifold Security. Automated installs can pull the wrong extension before review, so provenance checks have to happen before package resolution starts.

Editorial analysis by NHI Mgmt Group, based on content published by Manifold Security: “77 "Evil Twin" Open VSX Extensions: 19 Copy Private Repo and CI Data to a New Domain”.

Practitioner guidance

• Tighten extension allowlisting for automated installs Require explicit approval for editor extensions installed by devcontainers, images, or agent workflows, and restrict those workflows to verified publishers and approved registries.
• Audit developer and build images for squatted package names Search .vscode/extensions.json, .devcontainer/devcontainer.json, and image build logic for extension IDs that resolve to Open VSX or other alternate registries without publisher verification.
• Treat workspace metadata as sensitive Classify git remote URLs, branch names, repository paths, and CI project identifiers as sensitive telemetry when they appear in editor or extension data flows.

Bottom line: Counterfeit extensions can weaponise ordinary package resolution when automation trusts names more than publishers.

Glossary terms: Combo Squatting, Repository Identity, Publisher Verification, Automated Package Resolution

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →