What Happened

A cluster of 77 Open VSX evil twin extensions impersonated real developer tools and quietly transmitted data about the systems and development machines they were installed on. Security firm Manifold Security found the extensions, which were uploaded between July 26 and August 1, 2026. Open VSX removed all of them on August 3.

The researchers, Ax Sharma and Cody Nash, reported that most of the packages sent little more than the machine's hostname. Nineteen of them sent a detailed description of the machine, the repository open in the editor, and the CI system the editor was running inside. Both sets share the same exfiltration domain, mangorbit[.]com, which was registered on July 15, eleven days before the first packages were published.

How the Attackers Worked

The extensions were cleverly disguised. They reused the names, namespaces, and descriptions of real Microsoft VS Code Marketplace extensions, but they were published through unrelated accounts and given low version numbers like 0.0.1. The main change was swapping the contents of the bundled extension.js file with capabilities to capture and transmit data, while framing the collection as "anonymous usage metrics."

None of the extensions provide the advertised functionality from their listings. Instead, they display a status bar item along with a message that says they are active, and then fire the data exfiltration step.

What Data Was Stolen

The first set, 58 lightweight tools, exfiltrated the hostname and, in some cases, the workspace folder name or editor version.

The remaining 19 were reconnaissance payloads that transmitted a fuller picture of the developer environment:

• Local hostname and OS username
• Editor name, version, host kind, and machine ID
• Platform and architecture
• Locale and timezone
• Open workspace folder name and full file system path
• From the .git directory: remote hosts, organizations, developer email domains, current branch, HEAD commit SHA
• Up to 60 installed extension IDs, plus any proxy hostname from the environment
• CI markers: GITHUB_REPOSITORY, CI_PROJECT_PATH, Azure DevOps collection URI, Buildkite organization, CircleCI project username, Codespace name, Gitpod workspace context
• The editor's own telemetry opt-out setting and whether it was enabled

The recon variant also read the workspace's devcontainer.json or .vscode/extensions.json to detect whether the extension install came from a repository's configuration or a human choice.

Persistence and Resilience

The malware has contingency plans in case the primary domain is blocked. It queries a DNS TXT record for a fallback exfiltration URL, so even if the main endpoint is taken down, the payload can keep working. The recon variant retries hard: attempts come at roughly 15 minutes, 50 minutes, and 3.5 hours, then every 7-8 hours, resuming on every editor restart and only giving up after seven days. A machine that is offline, firewalled, or behind a proxy that drops the first request gets asked again for a week.

What This Means for Developers

Open VSX is the default registry for VSCodium and a key marketplace for VS Code-based editors. The attack shows that marketplace extensions are a prime supply chain vector for developer data: hostnames, secrets, git history, CI configuration, and machine identity are all targetable through a trust path developers rarely audit.

The campaign also overlaps with the ChainDrop npm worm, which planted malicious hooks in Claude Code and VS Code config files to reach developers through repositories. Both attacks show that the developer's toolchain, not just the production application, is the target.

How to Protect Yourself

1. Audit installed extensions in all code editors. Remove any extension you do not recognize, especially low-version packages (0.0.1) that mirror well-known publishers.
2. Compare the publisher account against the official one from a vendor site or blog before installing.
3. Check that the extension ID matches the official namespace of the tool (for example, a configcat extension should be published under the ConfigCat publisher account).
4. Try the extension in a disposable VM or container first if you install it for work.
5. Restrict extension auto-update and telemetry settings in the editor.
6. In organizations, deploy an allowlist of approved extension IDs and publishers through the shared settings or a management layer.
7. Monitor DNS logs for mangorbit[.]com and any newly registered domains delivering similar payloads. Block them at the network edge.
8. Keep registry integrity in mind: Open VSX has its own verification flow, but everyone confirmed that the marketplace is a better place when extensions are checked for behavior before release. Until then, treat every extension install as a risk decision.

Detection

• Network level: block mangorbit[.]com and watch for DNS TXT queries asking for fallback exfiltration endpoints.
• Endpoint: check for extensions installed from unknown publishers with names matching a known good extension but version 0.0.1.
• The telltale is the status bar message claiming the extension is active while no advertised functionality exists.

Frequently Asked Questions

Were these extensions in the official VS Code marketplace?

No. The campaign targeted Open VSX, which is a distinct registry used by VSCodium and some corporate VS Code setups. The same impersonation technique could be used anywhere, though, so the advice applies to all marketplaces.

What data did the malicious code steal exactly?

In the lightweight set: hostname and sometimes workspace name. In the recon set: machine and workspace metadata, git remote details, installed extensions, CI environment variables, and editor telemetry state.

Could the extension be a breach that goes to a repository?

In the recon variant the code reads the workspace's .git directory, so any private git remote URL, organization name, email domain, or commit hash tied to that workspace could be observed. If any credentials are stored in your editor or workspace environment, an attacker could also steal those.

Is Open VSX still safe to use?

Yes. The extensions were removed from Open VSX as of August 3. The marketplace as a whole remains usable. The incident is a reminder that extension installs should be audited like any other third-party dependency.

Conclusion

The Open VSX evil twin campaign is a reminder that extension marketplaces are developer supply chains: they sit right next to package registries and source control in the trust stack. The attacker did not exploit a complex code bug. The illusion was the whole attack. Using the familiar namespace of a well-known extension, an unrelated publisher account, and low version numbers, they built a covert data collection network. When the publisher pattern looks odd for a package you rely on, verify the publisher, review what the extension can access, and watch your network for outbound DNS.

---

Sources: The Hacker News, Manifold Security blog