77 Open VSX Extensions Harvested Developer Data

For six days at the end of July, a developer installing a Python linter or a theme pack from the Open VSX marketplace had a reasonable chance of installing something else too: a beacon that measured their machine, read their Git remote, counted their other extensions, and phoned the results to a domain registered eleven days earlier. Manifold Security counted 77 of these counterfeit packages. None of them stole a single line of source code, and that is the part worth paying attention to.

Key Takeaways

• Manifold Security identified 77 counterfeit "evil twin" extensions published to the Open VSX marketplace between July 26 and August 1, 2026, all removed by August 3.
• 58 of the extensions collected minimal system data, while 19 performed deep reconnaissance covering Git repository metadata, CI provider identifiers, and up to 60 installed extension IDs.
• All 77 extensions beaconed to mangorbit[.]com, a domain registered on July 15, 2026, using rotating subdomains and DNS TXT records as fallback endpoints.
• The extensions did not touch source code, credentials, authentication tokens, SSH keys, or browser data, which is precisely why static malware scanning had nothing to flag.
• The packages impersonated publishers including AMD, Azure, Salesforce, Hyperledger, LEGO Education, IOTA, and a US government agency.

What Is Open VSX and Why Does It Matter?

Open VSX is the vendor neutral extension registry that every VS Code fork depends on, because Microsoft's own marketplace is licensed for Microsoft's own builds only. When Cursor, Windsurf, VSCodium, Gitpod, Amazon's Kiro, or Google's Antigravity fetch an extension, they fetch it from Open VSX, operated by the Eclipse Foundation.

That makes the registry far more load bearing than a raw count of 77 packages suggests. The Eclipse Foundation reports the registry now hosts more than 12,000 extensions from over 8,000 publishers and serves more than 600 million downloads per month. Every AI coding editor that markets itself as a VS Code replacement inherits Open VSX as its software supply chain, and most of their users have no idea they switched registries at all.

What Did the Extensions Actually Collect?

The campaign ran in two tiers, and the gap between them is stark.

The 58 low tier extensions took the basics: machine hostname, and in some variants the workspace folder name and editor version. Enough to confirm an install happened and roughly where.

The 19 high tier extensions built something closer to a dossier, according to Manifold's findings reported by BleepingComputer:

• OS username, hostname, and machine identifier
• Editor name and version, platform architecture, locale, and timezone
• Workspace name and its full filesystem path
• Git remote hosts and organizations, plus the developer's email domain
• Current branch name and HEAD commit hash
• Up to 60 installed extension identifiers
• CI and cloud environment identifiers for GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces, and Gitpod

Nothing on that list is a secret in the cryptographic sense. Every item is available to any extension through documented editor APIs, which is exactly the problem.

How Did the Beacons Reach Home?

All 77 extensions transmitted to a single domain, mangorbit[.]com, registered July 15, 2026, and they were built to keep transmitting even when blocked. Traffic moved through pulse., pulse2., and api. subdomains, plus randomized hostnames under cb.mangorbit[.]com to defeat simple blocklist matching.

Two details separate this from lazy malware. First, the extensions could query DNS TXT records to fetch replacement endpoints, so takedown of a hardcoded URL would not end collection. Second, they retried transmission for up to seven days. A developer machine that was offline, firewalled, or air gapped for a weekend would still deliver its payload the following Tuesday.

Nearly every package carried version 0.0.1 and an individual tracking identifier, letting the operator attribute each data point to a specific installation rather than a generic pool.

Why "Only Telemetry" Is a Distinction Without a Difference

Manifold declined to speculate on the operator's intent and was explicit that no code, credentials, tokens, SSH material, or browser data were taken. Read that as reassuring at your own risk.

Combine a Git remote organization, a branch name, a HEAD commit hash, an employee email domain, a CI provider, and a list of 60 installed extensions, and you have not collected telemetry. You have identified a specific engineer, at a specific company, working on a specific private repository, in a specific build pipeline. That is a targeting package. It tells an attacker which organizations run Buildkite instead of GitHub Actions, which teams have an unpatched dependency scanner installed, and which individual developer has commit access to the repo worth compromising.

The same logic governs spear phishing selection. Knowing that a developer at a named company is on a branch called payments-refactor is worth more to an attacker than a stolen password, because it tells them what to ask for and who will believe the request.

Who Did They Impersonate, and Why Did It Work?

The packages reused the names, namespaces, and descriptions of real extensions while publishing from unrelated accounts, borrowing the identities of AMD, Azure, Salesforce, Hyperledger, LEGO Education, IOTA, and a US government agency.

This is the third Open VSX incident we have covered in six months, after GlassWorm's macOS campaign in February and the multi agency takedown of the GlassWorm botnet in May. What makes this one different is timing. The Eclipse Foundation began rolling out pre publish security checks in February 2026, explicitly designed to catch "namespace impersonation designed to mislead users." Five months later, 77 impersonating packages published successfully.

That is not a failure of the scanner so much as a demonstration of its scope. Static analysis hunts for malicious behavior. Reading vscode.env.machineId and posting it over HTTPS is not malicious behavior by any signature. It is what half the legitimate extensions in the registry do.

How Is This the Same as an Email Tracking Pixel?

Structurally, it is the same system. A tracking pixel is a 1x1 transparent GIF carrying a unique per recipient identifier that fires a request the moment an email renders, then retries on every subsequent open. These extensions were that architecture with a richer payload: a unique per install identifier, a silent outbound beacon, rotating fallback endpoints, and a retry window measured in days rather than milliseconds.

Version 0.0.1 across the board is the giveaway. Nobody iterating on malware ships 77 packages at v0.0.1. That is the signature of a collection campaign, not an exploitation campaign, and collection campaigns are the native grammar of the ad tech industry. Princeton researchers found in a study of email tracking that 70% of emails in their corpus contained resources classified as trackers, with roughly 29% leaking the recipient's address to a third party. The playbook is mature, well documented, and now portable.

Email users should care because this is the direction of travel. The same silent measurement pattern already normalized in your inbox has appeared in browser extensions that quietly shipped a browsing collector to 1.6 million users, in 82 Chrome extensions legally selling browsing data, and now in the IDE. Each surface arrives with the same defense: it is only telemetry, nothing was stolen, the data is anonymous. It was not anonymous in 2018 and it is not anonymous with a commit hash attached.

What Developers Should Do Now

Audit what is installed. In a VS Code fork, code --list-extensions (or the fork's equivalent binary) dumps the full list in seconds. Anything at version 0.0.1 with a publish date in late July deserves a hard look.

Check publisher identity, not extension name. Open VSX shows a verified indicator only when the publishing account belongs to a namespace with at least one owner, per the registry's namespace access rules. An unverified badge on a package claiming to be from Azure is the entire tell.

Watch outbound DNS from developer machines. Beacon architectures fail loudly against egress monitoring and succeed silently without it, and the DNS TXT fallback in this campaign means blocking a single domain is not enough.

Finally, stop treating extension telemetry as background noise. Your editor knows your employer, your repository, your branch, and your build system. Any process with read access to that is holding a map of your organization, and 77 packages just proved how cheaply someone can ask for it.