Open VSX has removed 77 malicious extensions that impersonated legitimate developer tools and funneled machine, project, and CI/CD data to a single attacker-controlled domain, according to an analysis from security firm Manifold Security. The extensions were pulled from the marketplace on August 3, days after security researchers identified a two-tier payload design split between lightweight telemetry collectors and more aggressive reconnaissance components.
How the 77 Evil-Twin Extensions Masqueraded as Legitimate Developer Tools
The malicious packages were uploaded between late July and the start of August, reusing the names, namespaces, and descriptions of real extensions while publishing through unrelated accounts at low version numbers such as 0.0.1. Manifold Security found that the bundles swapped in a data-capturing extension.js file framed as “anonymous usage metrics,” and that none of the advertised functionality actually worked. A developer who installed one of the lookalikes had no reason to suspect the code was anything other than a fresh release of a familiar tool.
The 19 Recon Payloads and the Developer Data They Collected
Most of the packages, 58 of the 77, operated as lightweight hostname and telemetry collectors. The remaining 19 carried a heavier reconnaissance payload that exfiltrated the hostname, OS username, editor name and version, machine ID, platform and architecture, locale and timezone, workspace folder name, and the full filesystem path of the workspace. The recon variants went further, inspecting .git metadata for remote hosts, organizations, email domain, branch, and HEAD commit SHA, and enumerating up to 60 installed extension IDs.
CI Environment Values and the mangorbit[.]com Exfiltration Channel
The recon extensions also reached into CI environments, pulling values such as GITHUB_REPOSITORY, CI_PROJECT_PATH, Azure DevOps collection URIs, Buildkite organizations, CircleCI user identifiers, Codespace names, and Gitpod URLs, and read the editor’s telemetry opt-out setting. All 77 packages sent data to mangorbit[.]com, a domain registered 11 days before the first packages were published. The recon variant included a retry mechanism that attempted delivery at 15 minutes, 50 minutes, and 3.5 hours before settling into a 7- to 8-hour cycle, resuming on editor restart and giving up after seven days, with a DNS TXT fallback exfiltration URL in case the primary domain was blocked.
Why the Open VSX Purge Points to a Broader Developer-Ecosystem Campaign
Manifold Security disclosed the Open VSX findings alongside analysis of a separate npm worm campaign, indicating a coordinated wave of attacks on developer-ecosystem infrastructure. Developer workstations and CI/CD pipelines are high-value targets because they hold source code, credentials, and deployment secrets, and the specific data the recon variants collected — Git organizations, CI environment variables, and workspace paths — is exactly the material an attacker would use to map a target organization before deeper intrusion.
The Uninstall Guidance and Signs of mangorbit[.]com Exfiltration
Open VSX removed the packages, and Manifold Security published indicators so affected users can check for signs of exfiltration to mangorbit[.]com. The recommended response for anyone who installed one of the 77 extensions is to uninstall it and review whether any data reached the attacker domain. Because the extensions were designed to look like legitimate tools, defenders cannot rely on the marketplace having caught them quickly; the upload window ran for roughly a week before the takedown.
What the 77-Extension Purge Means for Developer Security
The episode shows that public extension marketplaces remain a trusted distribution channel attackers can poison, and that the trust developers place in a marketplace’s catalog is itself an attack surface. The scale here — 77 packages impersonating real tools — shows how supply-chain operators have moved from scattering a few typosquatted names to cloning entire namespaces in bulk.
The data the reconnaissance tier collected is worth treating as a staging event rather than a one-time theft. Machine identifiers, workspace paths, Git remotes, and CI values together let an attacker fingerprint a developer’s entire build and deployment environment, which lowers the barrier to follow-on attacks on source code repositories and production credentials. For organizations that rely on open-source extensions in their toolchain, the practical consequence is that catalog appearance and download counts offer limited assurance, and the supply-chain risk now extends to the plugins developers install every day.
The broader pattern also connects the extension storefront to the npm registry: when two developer-ecosystem compromises are disclosed within the same window, they signal that the software supply chain’s weakest link is the trusted distribution surface itself, not any single registry’s controls. The question that follows is whether marketplaces will begin treating catalog publishing with the same verification rigor they already apply to critical dependency chains.
