Open VSX: 77 malicious evil twin extensions were stealing data

Seventy-seven malicious extensions in the Open VSX marketplace were found to be impersonating legitimate software development tools while also leaking sensitive data from the systems of the developers who installed them. The evil twin extensions — as researchers called them — were uploaded to the repository between July 26 and August 1, 2026 , and were removed on August 3, 2026, according to cybersecurity firm Manifold Security. The case marks yet another blow to the software supply chain, this time targeting the developers themselves.

See also: GlassWorm campaign: 73 new malicious Open VSX extensions

According to security researchers Ax Sharma and Cody Nash, most of the malicious extensions were limited to sending the hostname of the machine, while in some cases they also included the name of the working folder or the version of the editor. However, 19 of the 77 extensions turned out to be much more dangerous: they collected detailed information about the machine, the repository that was open in the editor, and the CI system in which the editor was running. The remaining 58 were characterized as “lightweight” data extraction tools.

All of the extensions shared the same data extraction domain, mangorbit[.]com, which was registered on July 15, 2026 — 11 days before the first malicious posts. This proves that the attack was planned and coordinated, and not random or opportunistic. The discovery was made through behavioral correlation: the researchers identified the extensions because they all communicated with the same domain and exhibited similar data extraction routines.

How evil twin extensions worked in Open VSX

The attackers’ strategy was simple but effective: they copied the names, namespaces, and descriptions of real Open VSX extensions , but uploaded them through different, unrelated accounts. Most of them are version 0.0.1 , while the main malicious payload replaced the logic of the extension.js file with code to collect and transmit data. To avoid suspicion, the extensions displayed an item in the status bar indicating that they were active before performing the data extraction step — presenting the collection as “anonymous usage metrics.”

None of the 77 extensions offered the functionality they advertised. Instead, they silently executed data extraction code immediately upon activation. The data collected by the most advanced variants included: local hostname and username , editor name and version, host type and machine ID, platform and architecture, locale and timezone, as well as the folder name and full filesystem path of the open workspace.

Particularly concerning is the inspection of the .git : the most capable variants extracted information about Git remote hosts and organizations, the developer's email domain, the current branch, and the HEAD commit SHA hash. They also listed up to 60 installed extension IDs and read environment variables from CI/CD such as GitHub Actions, Azure DevOps, Buildkite, CircleCI , and Gitpod.

See also: GlassWorm: 72 malicious Open VSX extensions target developers

Persistence and fallback mechanism of evil twin extensions

One of the most worrying features of the campaign is its sophisticated persistence mechanism. The malicious code has a backup plan: in case the main domain mangorbit[.]com is blocked or down, the malware queries a DNS TXT record to retrieve an alternative data extraction URL. This suggests that the attackers had anticipated the possibility of their infrastructure being blocked.

The recon also has a retry mechanism that triggers data collection at regular intervals: approximately 15 minutes, 50 minutes, and 3.5 hours after initial activation, and then every 7-8 hours. The process repeats itself every time the editor is restarted and only stops after 7 days. This means that even if a machine was offline during the first attempt, the data would be extracted later. Importantly, the researchers noted that the extensions did not access source code, credentials, authentication tokens, SSH hardware, or browser data — the campaign focused on mapping the environment for future targeted attacks.

The context of this attack is not isolated. Earlier in 2026, the GlassWorm campaign compromised multiple extensions and targeted both Open VSX and the Microsoft VS Code Marketplace . A malicious Solidity extension was also found to be using on-chain Ethereum command-and-control and was removed the same day it was published. Separately, a vulnerability has been reported in Open VSX with the number CVE-2026-13323 , which affects version 0.1.0 and is related to insecure serving of user-uploaded HTML — although this is different from the 77 extensions campaign.

How to protect yourself from evil twin extensions in Open VSX

Security experts recommend immediate action for anyone using Open VSX or VS Code in a professional environment. The first step is to inventory all installed extensions on developer machines, build agents, and remote development environments, immediately removing anything that is not trusted. It is critical to verify the identity of the publisher and not just the extension name displayed in the IDE, as malicious packages have been impersonating legitimate tools through names and descriptions.

Additionally, organizations should inspect outbound network traffic from developer workstations and CI for suspicious calls to unknown domains, especially newly registered infrastructure such as mangorbit[.]com. Extensions with version 0.0.1 that claim to mirror known tools or appear from unrelated accounts should be treated with increased suspicion. Finally, removing an extension from the marketplace does not automatically remove it from already infected machines — in the event of a malicious extension being installed, a full system reinstallation may be required.

See also: Open VSX: Addresses Token Leaks and Malicious Extensions

This case highlights once again the dangers of extension ecosystems for editors and IDEs. As the researchers point out, the Open VSX can be abused because users usually see the name of the extension in their editor, not the true identity and origin of the publisher. For more details. The developer community is urged to remain vigilant and adopt security practices that include regularly checking installed extensions and monitoring network traffic from their development environments.