By ByteBot
Between July 26 and August 1, attackers quietly uploaded 77 fake extensions to Open VSX — the default extension marketplace for Cursor, Windsurf, VSCodium, Google Antigravity, and every other VS Code fork that can’t touch Microsoft’s walled-off marketplace. The packages copied the names, namespaces, and descriptions of real tools from AMD, Azure, Salesforce, Hyperledger, LEGO Education, and others. All of them phoned home. The extensions were pulled from the marketplace by August 3. Your machine is a different story.
Still On Your Machine
Removing packages from Open VSX doesn’t uninstall them from developer machines, CI runners, or devcontainers that already pulled them. That’s the part worth paying attention to right now.
Manifold Security, who discovered the campaign, published a downloadable CSV containing all 77 extension IDs, version numbers, payload classification, and VSIX SHA-256 hashes. Run it against your installed extensions and your .vscode/extensions.json and .devcontainer/devcontainer.json files. If you find a match, remove the extension manually and block the attacker’s infrastructure domain: mangorbit[.]com and its subdomains (pulse.mangorbit.com, api.mangorbit.com).
What Was Stolen — and What Wasn’t
The 77 extensions split into two tiers. Fifty-eight lightweight variants sent only a hostname, workspace folder name, and editor version. Bad, but contained.
The remaining 19 were reconnaissance tools. They collected Git remote URLs, current branch, HEAD commit SHA, developer email domain, OS username, machine ID, locale, timezone, and up to 60 installed extension identifiers. In CI environments, they grabbed GitHub repository paths, Azure DevOps URIs, Buildkite slugs, CircleCI usernames, and Codespace or Gitpod context. Manifold’s researchers put it plainly: “On a build runner or cloud development environment, that is the full private repository name.”
Source code, credentials, SSH keys, and authentication tokens were not accessed. This was reconnaissance and environment mapping, not immediate exfiltration of secrets. The concern is what an attacker does next with a map of your repositories, branches, and CI pipelines.
How the Attack Worked
Evil twin attacks copy a legitimate extension’s identity exactly: same name, same namespace, same description. The attacker publishes under a different account at version 0.0.1, which reads as a first release. Once installed, the extension appears to function normally while transmitting data in the background.
The attacker registered mangorbit[.]com on July 15 — 11 days before the first packages appeared. The malware included retry logic that continued contact attempts every 15 minutes, escalating to daily retries for up to seven days. DNS TXT records provided a fallback mechanism to pivot to new infrastructure without updating the packages. The extensions listed documentation claiming they only transmitted “marker names,” never values. The code transmitted both, including full private repository paths in CI environments.
Why VS Code Fork Users Are Exposed
Microsoft’s marketplace terms prohibit non-Microsoft products from connecting to the official VS Code Marketplace. Cursor, Windsurf, VSCodium, Amazon Kiro, Google Antigravity, and Gitpod all default to Open VSX, which serves over 300 million extension downloads a month. Open VSX’s security model relies primarily on user reporting and compliance agreements rather than active scanning. That gap has been exploited repeatedly — GlassWorm ran three separate campaigns through Open VSX between January and March 2026, and namespace squatting was documented as a live attack surface in January.
Open VSX 1.0, the Eclipse Foundation’s managed registry upgrade, launched in July. This campaign followed within weeks. We covered the registry launch here — the managed infrastructure is an improvement, but it doesn’t fix the publisher verification gap that makes evil twin attacks trivial to execute.
What to Do Now
- Get the extension ID list. Download Manifold Security’s CSV from their full report and cross-reference against your installed extensions and workspace configs.
- Block the domain. Add
mangorbit[.]comand its subdomains to your hosts file or DNS blocklist. The extensions retry for up to seven days — blocking the domain stops remaining beaconing from machines you haven’t audited yet. - Pin your extensions. Specify publisher and version in
devcontainer.jsonand any internal extension mirrors. Unverified publishers on Open VSX are a blocking condition, not a yellow flag.
If you run CI pipelines on machines that install extensions from Open VSX, treat any match from the CSV as a potential environment compromise and audit recent pipeline runs for unexpected behavior.
Open VSX’s supply chain problem is structural. The managed registry was a step forward, but the marketplace still lacks the publisher verification controls that would make evil twin attacks meaningfully harder to pull off. Until that changes, extension hygiene is on developers — not the registry. BleepingComputer’s full writeup has additional context on the campaign scope.
