The "Evil Twin" Campaign Exposed
A massive supply-chain-style attack hit the open-source extension ecosystem for VS Code when researchers at Manifold Security uncovered 77 malicious packages masquerading as legitimate developer tools on the Open VSX marketplace. The campaign, dubbed "evil twin" by the researchers, was active between July 26 and August 1, 2026, and it managed to harvest sensitive information from developers' machines before being discovered and removed.
What makes this incident particularly concerning isn't just the sheer number of compromised packages — it's how cleverly they were constructed to blend in with legitimate extensions while quietly exfiltrating data about the systems they were installed on.
How the Malicious Extensions Operated
The attackers didn't just throw random malware at the marketplace. These packages were carefully crafted to impersonate real, trusted extensions. They reused the names, namespaces, and descriptions of legitimate VS Code Marketplace extensions, but published them through unrelated accounts. Most were assigned the low version number 0.0.1, which should've been a red flag, but the deception was convincing enough to trick developers into installing them.
Here's the thing that makes this campaign so insidious: the malicious packages didn't actually provide the functionality they claimed to offer. Instead, they replaced the legitimate extension's bundled extension.js file with code designed primarily to collect and transmit data. When developers activated these extensions, they'd see a status bar indicator or message claiming the extension was active — but that was just theater. Behind the scenes, the code was busy gathering information and sending it to the attacker's server.
The packages impersonated extensions associated with a wide range of technologies and organizations, including AMD, Azure, Salesforce, Hyperledger, LEGO Education, IOTA, and even a U.S. government agency namespace. That's a broad spread, suggesting the operator was casting a wide net rather than targeting specific organizations.
What Data Was Collected (and What Wasn't)
Manifold Security's analysis revealed two distinct tiers of data collection among the 77 malicious extensions. Fifty-eight of them sent only basic system information — primarily the machine's hostname, with some variants also sending the workspace folder name and editor version.
But the other 19 extensions were far more aggressive. Approximately four to five seconds after activation, they began collecting significantly more information, including:
- Operating system username and hostname
- Machine identifier
- Editor name and version
- Platform architecture
- Locale and timezone settings
- The name and full filesystem path of the workspace open in the editor
Even more concerning, these extensions inspected files in the workspace's .git directory to extract Git remote hosts and organizations, the domain of the developer's configured email, the current branch, and the HEAD commit hash. They also enumerated up to 60 installed extensions and collected identifiers from CI and cloud development environments, including GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces, and Gitpod.
To be clear, Manifold found that the extensions did not access source code, credentials, authentication tokens, SSH material, or browser data. They declined to speculate on the campaign's purpose, but collecting enough metadata to profile organizations, development environments, and private repositories is concerning enough on its own.
What's also unusual is that the Open VSX listings disclosed they collected what they called "anonymous usage metrics" and accurately stated they did not access source code or credentials. The extensions sent more data than disclosed, including CI information that could expose private repository names or paths. Some also checked whether they had been installed manually or automatically through a project configuration.
The Infrastructure Behind the Attack
All 77 extensions communicated with a server at mangorbit.com, which was registered on July 15, 2026 — eleven days before the first malicious packages appeared. This suggests the operator planned ahead, setting up infrastructure before deploying the extensions.
Most samples contacted pulse.mangorbit.com or pulse2.mangorbit.com, while others used api.mangorbit.com or randomized subdomains under cb.mangorbit.com. Each package included its own tracking identifier, allowing the operator to determine which specific counterfeit extension had been installed on a victim's machine.
Some variants were designed to keep trying to transmit the collected data for up to seven days. They also supported multiple collection endpoints and could query a DNS TXT record for a replacement URL if the hardcoded infrastructure stopped responding. That kind of resilience suggests someone who's dealt with takedowns before.
Why This Matters for Open Source Ecosystems
The Open VSX marketplace, an open-source alternative to the Microsoft-owned VS Code Marketplace, has always been positioned as a more transparent and community-driven platform. This campaign exposes the vulnerabilities that come with that model.
When anyone can publish extensions without the same level of scrutiny applied to commercial marketplaces, malicious actors have a clear incentive to create fake packages that mimic legitimate ones. The fact that 77 such packages were published and installed before discovery suggests the marketplace's moderation and review processes need significant strengthening.
The broader implication is that supply-chain attacks aren't just about compromising the software itself — they're about gathering intelligence that can be used for future, more targeted attacks. The metadata collected here could help attackers identify high-value targets, understand organizational development practices, and potentially plan more sophisticated intrusions.
What Developers Should Do Now
The malicious packages were removed from Open VSX by August 3, 2026, but that doesn't mean developers are safe. The packages would still need to be manually removed from developers' systems and applications.
Manifold recommends checking systems and workspace configuration files for extension IDs listed in its report and blocking the mangorbit.com domain, which is used by all 77 packages in the campaign. Developers who installed any of these extensions should:
- Review their installed extensions list in VS Code or compatible editors
- Remove any suspicious packages, especially those with version 0.0.1 that don't match known legitimate extensions
- Block the
mangorbit.comdomain at the network level - Monitor for any unusual network activity or DNS queries
The campaign serves as a reminder that in the open-source extension ecosystem, trust must be earned, not assumed. Just because an extension is available in a marketplace doesn't mean it's safe to install. Developers need to verify the publisher's identity, check the extension's reputation, and question packages that seem too good to be true — or that display version numbers like 0.0.1 for tools that should be mature and well-established."