The short answer
77 malicious extensions appeared on Open VSX Registry between July 26 and August 1, 2026, impersonating legitimate tools from AMD, Azure, Salesforce, Hyperledger, and other trusted namespaces. Manifold Security researchers Ax Sharma and Cody Nash discovered the campaign. Open VSX removed all 77 packages by August 3, 2026 — but extensions already installed on developer machines and CI runners were not automatically uninstalled and continue to exfiltrate data until manually removed.
The stolen data did not include source code, credentials, or tokens. Instead, the attack mapped developer organizations: CI environments, Git remote URLs, branch names, commit SHAs, developer email domains, and workspace paths. This reconnaissance tier is the precursor to highly targeted follow-on attacks.
What is Open VSX and who uses it
Open VSX Registry (open-vsx.org) is an open-source extension marketplace for VS Code-compatible editors that do not use Microsoft's proprietary VS Code Marketplace. It serves as the default extension source for VS Codium (the open-source VS Code build without Microsoft telemetry), Gitpod, GitHub Codespaces' alternative mode, Eclipse Theia, and a range of browser-based cloud development environments popular in EU engineering teams.
Unlike the Microsoft marketplace, Open VSX accepts publisher registrations without the same level of organizational verification, which made it a viable target for namespace squatting — registering accounts that appear to belong to organizations like AMD or Salesforce without actually being affiliated with them.
The Microsoft VS Code Marketplace was not affected by this campaign. Teams using only the official VS Code application with Microsoft's marketplace are not at risk from these specific 77 packages.
How the attack worked: two tiers of exfiltration
The attack began on July 26, 2026, eleven days after the attackers registered their C2 domain mangorbit.com on July 15. Extensions were published at version 0.0.1 from pseudonymous accounts that adopted the names, namespaces, descriptions, and branding of legitimate popular extensions. The impersonated namespaces included AMD, Azure (Microsoft), Salesforce, Hyperledger, LEGO Education, IOTA, and at least one U.S. federal government agency identifier.
The campaign operated in two distinct tiers. The first tier — 58 extensions — collected only basic system reconnaissance: hostname, workspace folder path, operating system platform and architecture, machine ID, and timezone. The second tier — 19 extensions — ran a substantially heavier payload designed to map an organization's entire development and CI topology.
All data was transmitted to attacker-controlled infrastructure at mangorbit.com, with a DNS TXT record fallback mechanism that allowed the C2 endpoint to be silently swapped if the primary domain was blocked. This anti-blocking design indicates the campaign was engineered for persistence, not a quick smash-and-grab.
What data was actually stolen
The heavier-tier 19 extensions exfiltrated the following data points from each affected developer machine:
- Git intelligence: remote host and full URL, organization and repository name, branch name, HEAD commit SHA, developer email domain from git config
- CI environment markers: presence and identity of GitHub Actions, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces, and Gitpod configurations
- Machine identity: hostname, OS username, machine ID, platform, architecture, locale, timezone
- Extension inventory: up to 60 installed extension IDs from the same editor instance
- Workspace topology: full file-system workspace path
Manifold Security and Open VSX confirmed that no source code files, API credentials, auth tokens, SSH private keys, or browser credentials were directly captured. The attack was designed for intelligence collection — mapping what an organization is building, where its code lives, who is working on it, and what CI systems it uses — rather than immediate credential theft.
C2 infrastructure: how attackers built their collection layer
The attackers registered mangorbit.com on July 15, 2026 — exactly eleven days before the first malicious packages appeared on Open VSX. The domain was configured with four subdomains: pulse.mangorbit.com, pulse2.mangorbit.com, api.mangorbit.com, and cb.mangorbit.com, allowing load distribution and endpoint rotation.
The DNS TXT fallback mechanism is particularly significant from a threat-modeling perspective. If a network perimeter blocks mangorbit.com at the DNS level, the extension can query a DNS TXT record to obtain a replacement endpoint without a software update. This means simple domain-based blocking is insufficient for remediation — teams need to audit historical outbound traffic rather than relying on current-state firewall rules to determine whether data was exfiltrated.
Why CI and Git metadata is valuable to attackers
The stolen CI and Git intelligence has direct value for follow-on attacks. A threat actor who knows an organization's Git remote URL, branch naming convention, HEAD commit SHA, and CI provider can construct highly targeted phishing campaigns against developers — for example, spoofing a CI failure notification that looks precisely like the victim organization's actual pipeline output, referencing the correct branch name and commit reference.
The extension inventory data compounds this: knowing which 60 tools a developer has installed enables attackers to craft malicious updates targeting specific tools already trusted in that environment. This shifts the attack from generic supply-chain phishing to precision targeting informed by actual environment reconnaissance.
This is a pattern shift worth noting in threat models. Instead of poisoning packages at runtime — the method used in many supply-chain attacks on npm and PyPI — this campaign attacked the developer's local IDE environment directly. IDE-layer attacks survive container isolation: a developer's local editor runs outside any container, so container-level security controls (image scanning, runtime policy enforcement) do not apply to extension execution.
What it means for US & EU software teams
The Open VSX attack illustrates an underweighted risk category: the developer toolchain itself as an attack surface. Most organizations invest heavily in securing what their software produces — source code scanning, dependency auditing, container image analysis, runtime protection. Fewer maintain a formal inventory of what their developers use to produce that software: editors, extensions, local build tools, CLI plugins.
For US teams: the SDLC supply-chain risk here is direct. If a developer on a regulated project — FinTech, HealthTech, a DoD-adjacent contractor — had one of these extensions installed, the CI mapping data may constitute a material organizational disclosure depending on the sensitivity of the repositories involved. Teams that cannot rule out installation should treat this as a disclosure event and notify their security team.
For EU teams: the GDPR and NIS2 implications depend on whether the exfiltrated metadata (workspace paths, developer email domains, Git remote URLs) constitutes personal data or organizational confidential data under applicable data agreements. EU-based teams using Gitpod or cloud-based Theia instances should verify whether their Data Processing Agreements cover extension-layer activity in their development environment. Teams with a NIS2-reportable classification should assess whether this constitutes an incident under Article 23 notification requirements.
The broader takeaway: extension marketplaces without strong publisher verification are a repeatable attack surface. This is the second major extension-based supply-chain campaign in twelve months following the VS Code Marketplace fake extension incidents of 2025. Organizations should establish an explicit policy for which extension sources are approved, how extensions are reviewed before installation on developer machines that touch regulated or sensitive codebases, and how extension inventory is tracked as part of SDLC asset management.
Remediation steps
For teams that may have been exposed, here is the recommended sequence:
- Check the extension list. Obtain the full list of 77 flagged package names from the Manifold Security research report. Search installed extensions in any Open VSX-based editor (VS Codium, Gitpod workspace, Codespaces alternative mode, Eclipse Theia) for matches. Uninstall any found immediately.
- Audit network logs for C2 connections. Search outbound traffic logs — DNS query logs, proxy logs, firewall egress logs — for connections to
mangorbit.com,pulse.mangorbit.com,pulse2.mangorbit.com,api.mangorbit.com, andcb.mangorbit.com. Filter by the date range July 26 – present. - Assess what data may have been exfiltrated. If network logs show connections to
mangorbit.com, determine which tier of extension was installed (58 basic or 19 heavy) and classify accordingly. If heavy-tier data was exfiltrated, notify your security team and review your incident response and disclosure obligations. - Rotate credentials if warranted. If the affected workspace had active Git credentials, CI tokens, or service account keys accessible during the period of infection, rotate them as a precaution — even though Manifold Security found no evidence of direct credential capture in this campaign.
- Update your extension policy. If your organization does not have a formal approved-extensions list for developer tooling, establish one. Restrict installation to vetted, inventoried extensions and enforce the policy through workspace configuration or IT-managed editor profiles.
Frequently asked questions
What is Open VSX Registry and who uses it?
Open VSX Registry is an open-source extension marketplace for VS Code-compatible editors that do not use Microsoft's proprietary VS Code Marketplace. It is the default registry for VS Codium, Gitpod, GitHub Codespaces, Eclipse Theia, and other open-source or cloud-based development environments. Developers who prefer open-source editors or work in browser-based IDEs rely on Open VSX instead of the Microsoft marketplace.
Was the VS Code Marketplace affected?
No. The 77 malicious extensions were planted exclusively on the Open VSX Registry. The Microsoft VS Code Marketplace has separate ownership and publication controls and was not part of this campaign. Teams using only the official VS Code application with Microsoft's marketplace are not affected by these specific packages.
What data did the 77 malicious extensions steal?
The campaign ran in two tiers. Fifty-eight extensions exfiltrated basic system data: hostname, workspace folder, OS platform and architecture, machine ID, and timezone. The remaining 19 added Git remote host and URL, organization and branch name, HEAD commit SHA, developer email domain, CI environment markers for GitHub Actions, Azure DevOps, Buildkite, CircleCI, Codespaces, and Gitpod, and up to 60 installed extension IDs. No source code, credentials, tokens, or SSH keys were directly stolen.
Were extensions removed from developer machines automatically?
No. Open VSX removed all 77 packages from the registry on August 3, 2026, preventing new installs. However, extensions already installed on developer machines or CI runners were not automatically uninstalled. Developers must manually check their extension list and remove any flagged packages still present.
How can software teams check if they were affected?
Review the full list of 77 flagged extension names published in the Manifold Security research report. In VS Codium or any Open VSX-based editor, open the Extensions panel and search for each flagged name. Then audit outbound network logs for connections to mangorbit.com and its subdomains covering July 26 onward. If any match is found, uninstall the extension, rotate affected credentials, and assess your incident disclosure obligations.
Sources
Manifold Security — Open VSX Evil-Twin Extensions (primary research), August 4, 2026
The Hacker News — Open VSX Removes 77 Malicious Evil-Twin Extensions, August 5, 2026
BleepingComputer — 77 Open VSX extensions found harvesting developer info, August 4, 2026