A group of researchers has found 77 malicious ‘evil twin’ extensions on the Open VSX platform. They mimicked popular or useful development tools, but were designed to collect information and send it about the machines and development environments where they were installed.
According to Manifold Security, the affected extensions have now been removed from Open VSX (status as of August 3, 2026). The campaign ran roughly from July 26 to August 1, 2026, and the extensions sent the stolen data to a single shared exfiltration domain.
What exactly was found on Open VSX?
The researchers describe a cluster of extensions that presented names, namespaces, and descriptions matching existing Open VSX tools. The packages were published via other (standalone) accounts and were given low version numbers, such as 0.0.1. In many cases, it appeared that the functionality shown in the listing did not match what the code actually does.
What stands out: the malicious code replaced the contents of the extension.js file with functionality capable of collecting and transmitting data. The extensions framed this activity as ‘anonymous usage metrics’, while in reality it was reconnaissance and data exfiltration.
What did the data exfiltration consist of?
The 77 extensions can roughly be divided into two categories.
- 58 ‘lightweight’ tools: these primarily gathered basic information such as the hostname. Sometimes they also collected additional details like the name of the workspace folder or the editor version.
- Reconnaissance payloads: these went further and delivered a much richer set of developer-related data. This included, among other things, the local username, editor name and version, host characteristics and machine ID, platform and architecture, locale and timezone, and information about the opened workspace and the folder structure.
Both variants used the same domain destination for outbound messages. In every identified extension, data was sent to mangorbit[.]com. According to the researchers, that domain had already been registered on July 15, 2026, before the first packages appeared.
How ‘evil twin’ extensions present themselves
In many of the abused extensions, the visible “function” mostly consisted of a status bar item and a message indicating the extension is active. Only afterward did the data-collection step happen in the background.
An additional signal for defenders is that the extension listing appears to point to a specific functionality, but in practice that functionality is not delivered. Instead, the real logic focuses on identifying the environment and retrieving configuration and context data.
Extra steps in the reconnaissance variant
The second cluster of extensions included additional techniques to better understand development workflows. The following actions, among others, appeared repeatedly:
- Inspecting files in the .git directory of the workspace to identify Git remote hosts and organizations, including domains related to email configuration, the current branch, and the HEAD commit SHA.
- Enumerating up to 60 installed extension IDs and deriving a proxy host name from the environment.
- Detecting CI markers and then reading multiple CI variables, including values for GITHUB_REPOSITORY, CI project paths, Azure DevOps collection URIs, Buildkite organization slugs, CircleCI project users, and Gitpod context.
- Checking whether the editor telemetry opt-out is enabled and passing along that status.
That means the extensions target not only the system, but also the workflow in which a developer works—giving attackers insight into how and where code is built, shared, and published.
Contingency: fallback via DNS TXT
Additionally, a mechanism is described for resilience if the primary exfiltration domain is no longer reachable. The malware can query a DNS TXT record to obtain an alternative outbound URL when the original destination is blocked or disappears.
A form of repeated retry behavior was also observed. In the reconnaissance variant, attempts to collect and transmit data were carried out at intervals of approximately 15 minutes, 50 minutes, and 3.5 hours, after which the process resumed later. The researchers report that it stops only after a period of seven days, even if the machine is offline, behind a firewall, or if a proxy removes the first request.
Why timing and conditions matter
This approach points to a goal that goes beyond a one-time “test.” By trying again later, the attackers increase the chance of fully observing the environment when the developer or the environment (for example, an editor restart) becomes active again.
In addition, the reconnaissance variant checks whether workspace-specific configuration files contain a reference to the extension ID. This helps distinguish between extensions installed via a repository configuration and extensions that were manually chosen by a human. In other words, the code tries to determine how someone ended up with the extension.
The list of abused extension names
The researchers shared the names of the 19 extensions from the second cluster. Examples include:
- amd.gaia-vscode
- artsy.artsy-studio-extension-pack
- configcat.configcat-feature-flags
- iotaledger.iota-move
- marketplace.visualstudio
- obyte.oscript-vscode-plugin
- openeuphoria.vscode-euphoria
- oss.sfmc-devtools-vscode
- rumbledb.jsoniq-vscode
- ssagov.uef-snippets
- taskfile.vscode-task
- doi.fileheadercomment
- mengsiCode.vscode-django-boilerplate
- move.move-analyzer
- uavcan.dsdl
- vs-publisher-988541.apexsql-power-tools
- casualjim.gotemplate
- jcamp.dotnet-test-provider-view
- superposition.supertoml-analyzer
Even if you don’t recognize any of these names right away, the broader pattern still matters: the same tactic—imitating the name/description and then rewriting the real extension code—can also show up in other (separate) ecosystems.
Which broader supply chain attack is connected to this?
The researchers place this Open VSX campaign in the larger picture of supply chain attacks. In an earlier report, it was mentioned that npm-related compromises also took place: 450 unique npm packages (2,244 artifacts) were allegedly abused to deliver an information stealer, and also to use a stolen npm token to publish manipulated variants.
That report called the campaign ChainDrop. It described how malicious releases could consist of variants of a self-propagating worm-like approach, which could also use stolen GitHub credentials to inject configuration files. This creates an additional developer-to-developer infection path.
If you want more context on the npm and ecosystem angle, this article may also be relevant: ChainDrop: 400+ NPM packages infected.
Why 2FA and blocking install scripts aren’t enough
The analysis highlights a key point: limiting risk with only “standard” measures is often not sufficient. OX Security emphasizes that you need a security layer that looks beyond simply blocking install scripts or enforcing two-factor authentication for maintainers.
Concretely, the idea is raised that packages should require granular permissions. So not only checking whether a maintainer uses 2FA, but also enforcing which actions a package is allowed—or not allowed—to perform, for example exfiltration of cloud keys and GitHub credentials.
What can you do right now if you work with Open VSX or similar tooling?
Because these attacks target the developer environment itself, the best starting point is visibility and control.
- Check installed extensions on developer workstations and in build environments. Pay special attention to extensions whose description doesn’t match their behavior.
- Limit rollout: prevent everyone from installing new or “suspicious” extensions without control. Use a whitelist or a managed deployment process.
- Monitor outbound network traffic from editor components. If an editor extension communicates with unexpected domains, that’s a red flag.
- Be mindful of CI context: given the interest in CI variables and Git information, it’s useful to strictly protect CI secrets and tokens and to segment them.
For more context on supply chain and attacks that try to get through by targeting the development chain, this related piece may help too: Malicious npm packages via supply chain: RAT alert.
Conclusion: respond quickly to Open VSX evil twin signals
The removal of 77 Open VSX evil twin extensions shows how attractive the development environment is for attackers: they can collect context there (hostname, workspace, editor and CI data) and then forward it.
The combination of misleading namespaces, rewriting the real extension code, and using a shared exfiltration domain makes this a recognizable pattern. By controlling extensions, tightening install policies, and safeguarding outbound communication, you reduce the chance that campaigns like this take hold in your environment.
Source: https://thehackernews.com/2026/08/open-vsx-removes-77-malicious-evil-twin.html
