77 extensions on the Open VSX marketplace impersonated legitimate developer tools while transmitting information about the systems and development environments where they were installed.
The "evil twin" technique used on Open VSX
Manifold Security discovered an "evil twin" campaign between July 26 and August 1, 2026 in which counterfeit packages reused the names, namespaces, and descriptions of real Open VSX extensions but were published through unrelated accounts. Most of the counterfeit packages were assigned the low version number 0.0.1, and the legitimate extension's bundled extension.js file was replaced with code designed to collect and transmit data. Instead of providing advertised functionality, the packages typically showed a status bar or a message saying the extension was active and then began sending information to an attacker-controlled server.
What the 77 packages communicated — and what they did not take
All 77 extensions communicated with a domain controlled by the operator: mangorbit[.]com, which was registered on July 15, 2026 — eleven days before the first malicious packages appeared. Most samples contacted pulse.mangorbit[.]com or pulse2.mangorbit[.]com; others used api.mangorbit[.]com or randomized subdomains under cb.mangorbit[.]com. Each package carried its own tracking identifier so the operator could determine which counterfeit extension a given installation corresponded to.
Manifold grouped the samples into two behavior classes. Fifty-eight of the extensions sent primarily minimal system information — mainly the machine's hostname and, in some variants, the workspace folder name and editor version. Nineteen of the extensions performed extensive reconnaissance approximately four to five seconds after activation. Those 19 collected the operating system username and hostname, machine identifier, editor name and version, platform architecture, locale, timezone, and the name and full filesystem path of the workspace open in the editor. They also inspected files in the workspace's .git directory to obtain Git remote hosts and organizations, the domain of the developer's configured email, the current branch, and the HEAD commit hash. The reconnaissance variants enumerated up to 60 installed extensions and collected identifiers from continuous integration and cloud development environments, including GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces, and Gitpod.
Manifold additionally reports that the extensions did not access source code, credentials, authentication tokens, SSH material, or browser data. The company declined to speculate on the operator’s intent.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scramble →Infrastructure, persistence, and evasive behavior
Some variants were designed to persist in their attempt to transmit collected data for up to seven days. The packages supported multiple collection endpoints and could query a DNS TXT record for a replacement URL if their hardcoded infrastructure stopped responding. Several samples also checked whether they had been installed manually or automatically through project configuration. These behaviors — tracking IDs per package, multiple endpoints, and DNS-based fallback — tied the 77 packages together through shared network and code activity, according to Manifold.
Targets impersonated and disclosure versus reality
The counterfeit packages impersonated extensions associated with a wide range of technologies and organizations, including AMD, Azure, Salesforce, Hyperledger, LEGO Education, IOTA, and a U.S. government agency namespace. Open VSX listings for the counterfeit packages disclosed that they collected what they called "anonymous usage metrics" and accurately stated they did not access source code or credentials. Manifold's analysis shows the extensions nevertheless transmitted more data than the listings disclosed — notably CI-related metadata that could expose private repository names or paths.
What this means for developers, enterprises, and open-source maintainers
- Developers: Packages were removed from Open VSX by August 3, 2026, but Manifold warns they still need to be manually removed from affected systems and applications. Developers should check workspace configuration files and extension IDs listed in Manifold’s report.
- Enterprises and security teams: Because all 77 packages used the same mangorbit[.]com domain, Manifold recommends blocking that domain. Teams should also look for unusual traffic to the pulse.mangorbit[.]com and pulse2.mangorbit[.]com subdomains and watch for long-running outbound attempts consistent with multi-day retry behavior.
- Open-source maintainers and package registry operators: The campaign illustrates how counterfeit listings that reuse legitimate names, namespaces, and descriptions can deceive users; publishers and registry operators should examine account provenance and versioning anomalies such as unexpected 0.0.1 releases.
Manifold Security tied the 77 packages to the same operator through shared data-exfiltration infrastructure, code, and network behavior but did not attribute the campaign. The packages’ removal from Open VSX halts further distribution, yet installations already present on devices will remain capable of sending metadata until manually cleaned. The record is clear: the counterfeit extensions sent more than the "anonymous usage metrics" they advertised, and the mangorbit[.]com infrastructure is the single choke point defenders can block to blunt the campaign's telemetry.
Source: BleepingComputer — 77 Open VSX extensions found harvesting developer info
