77 Open VSX Extensions Caught Exfiltrating Developer and CI Metadata

Developers relying on the Open VSX extension marketplace were targeted in a systematic “evil twin” campaign involving 77 malicious extensions designed to profile development environments and exfiltrate pipeline metadata. Discovered by researchers at Manifold Security between July 26 and August 1, 2026, the packages impersonated widely used tools across major tech ecosystems before being removed from the marketplace on August 3, 2026.

While developer environment extensions are increasingly targeted for credential theft and supply chain poisoning, this campaign focused primarily on pre-attack reconnaissance. The operators collected detailed operational context—including repository locations, developer identities, and continuous integration (CI) workflows—without directly tampering with source code or stealing authentication tokens.

The Mechanics of the “Evil Twin” Campaign

In developer tooling ecosystems like VS Code and Eclipse Theia, extensions run with the ambient privileges of the local user session. “Evil twin” attacks take advantage of this permissive model by publishing packages that clone the display names, descriptions, and namespaces of reputable extensions under unrelated publisher accounts.

In this campaign, the attacker registered packages across high-profile namespaces, including those associated with Azure, AMD, Salesforce, Hyperledger, LEGO Education, IOTA, and a U.S. government agency. Most packages were published with an initial version string of 0.0.1.

Instead of delivering legitimate utility, the bundled extension.js entry point was overwritten with basic telemetry code. When loaded into an editor, the extension displayed a standard status bar notification claiming the tool was active, while quietly launching a background exfiltration loop.

To obscure the activity, the marketplace listings explicitly stated that the tools collected “anonymous usage metrics” and did not touch source code or credentials. While technically true regarding credentials, the exfiltrated datasets went far beyond standard usage telemetry.

Deep Reconnaissance and Metadata Exfiltration

All 77 extensions relied on shared command-and-control (C2) infrastructure anchored at mangorbit[.]com, a domain registered on July 15, 2026—eleven days prior to the deployment of the first malicious packages. Each package was assigned a unique tracking identifier, allowing the threat actor to correlate exfiltrated data back to specific extension installs.

The extensions fell into two distinct operational variants based on payload complexity:

• Basic Footprinting (58 extensions): Transmitted lightweight system identifiers immediately upon startup, primarily targeting the local machine’s hostname, editor version, and active workspace folder name.
• Extensive Reconnaissance (19 extensions): Initiated an in-depth survey four to five seconds after editor initialization. These variants exfiltrated the OS username, machine ID, platform architecture, system locale, timezone, and the full local file system path of the open workspace.

For active projects containing a local .git directory, the reconnaissance payload parsed Git configuration files and metadata directly from disk. It extracted the Git remote host URL, organization namespace, developer email domain, active branch name, and current HEAD commit hash.

Additionally, the payload enumerated up to 60 installed editor extensions and identified integration markers for cloud development and CI/CD platforms, including GitHub Actions, GitLab CI, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces, and Gitpod.

To ensure delivery, the payload maintained a seven-day retry loop if the C2 server was unreachable. In addition to primary subdomains like pulse.mangorbit[.]com, pulse2.mangorbit[.]com, and api.mangorbit[.]com, the malware included logic to resolve DNS TXT records to acquire dynamic fallback endpoints if hardcoded infrastructure was taken offline.

Strategic Threat Context and Blast Radius

Reconnaissance campaigns targeting developer workstations serve as initial intelligence gathering for broader supply chain operations. By mapping internal repository naming structures, developer email domains, remote Git hosts, and CI/CD tools, an adversary can identify high-value targets within corporate networks.

Knowing whether a target uses GitHub Actions, CircleCI, or self-hosted GitLab instances allows threat actors to tailor subsequent spear-phishing campaigns, craft specialized malware targeting specific build systems, or attempt targeted credential stuffing against exposed enterprise single sign-on (SSO) gateways. Exfiltrating private file paths and repository names can also leak sensitive internal project codenames and intellectual property structures.

Because these packages were hosted on Open VSX—the default open-source extension registry for open-source builds of VS Code, VSCodium, Eclipse Theia, and cloud IDEs—the primary blast radius includes organizations maintaining open-source development stacks or automated containerized development environments (.devcontainer).

Detection and Remediation

While Open VSX removed the 77 packages from the public index on August 3, 2026, existing installations are not automatically deleted from local developer workstations, remote SSH development hosts, or pre-built container images.

Security teams should enforce the following remediation steps across dev environments:

1. Audit Installed Extensions: Query local extension directories (~/.vscode/extensions, ~/.vscode-oss/extensions) and development container manifests for extensions sending traffic to mangorbit[.]com or matching package IDs flagged in the campaign.
2. Network Blocking: Implement perimeter firewall and DNS sinkhole rules for mangorbit[.]com and all associated subdomains (*.mangorbit[.]com).
3. Inspect Git Configuration Exposure: Review developer workstations to ensure internal corporate repo URLs, hostnames, and commit histories aligned with sensitive projects were not exposed prior to package removal.
4. Enforce Registry Controls: Restrict developer environment configurations to fetch extensions exclusively from enterprise-approved internal mirrors or verified namespaces with enforced publisher authentication controls.