TL;DR: Between July 26 and August 1, 2026, someone uploaded 77 “evil twin” extensions to the Open VSX marketplace — byte-for-byte impersonations of real VS Code extensions, republished at version 0.0.1 under accounts that don’t own the namespace. Every one of them phoned home to mangorbit[.]com, a domain registered 11 days before the first upload. 58 sent lightweight system fingerprints; 19 went further and pulled your Git remotes, branch, commit email domain, and CI identifiers. Open VSX removed all 77 on August 3. If you run Windsurf, Cursor, VSCodium, or any other VS Code fork — they all pull extensions from Open VSX, not Microsoft’s marketplace — spend five minutes on the audit below.

	The campaign at a glance
Extensions removed	77, all linked by shared code and infrastructure
Upload window	July 26 – August 1, 2026
Removed from Open VSX	August 3, 2026
Discovered by	Manifold Security
Exfiltration domain	mangorbit[.]com (registered July 15, 2026 — 11 days pre-campaign)
Lightweight variants	58 — hostname, workspace folder name, editor version, installed-extension list
Aggressive variants	19 — Git remote host/org, branch, HEAD SHA, commit email domain, CI identifiers
What was NOT taken	Source code, credentials, auth tokens, SSH keys, browser data
Squatted namespaces	AMD, Azure, Salesforce OSS, Hyperledger, IOTA, Artsy, LEGO Education, a .gov agency, and marketplace.visualstudio

Honest take: This campaign stole reconnaissance, not secrets — and that should worry you more, not less. Someone spent money and three weeks of setup to build a map of which organizations’ developers run which editors against which private repos and CI systems. Maps like that get used. The immediate fix takes five minutes (audit below), but the durable lesson is that Open VSX namespaces are not identity-verified the way you assume they are, and every VS Code fork you use — Windsurf, Cursor, VSCodium — inherits that gap as its default extension source.

What actually happened

Manifold Security identified a cluster of 77 extensions on Open VSX — the Eclipse Foundation-run marketplace that serves nearly every VS Code fork — impersonating legitimate developer tools. The trick was blunt and effective: each malicious package republished the name, namespace, and description of a real VS Code Marketplace extension, almost always at version 0.0.1, from an account with no connection to the original author. The visible metadata looked right. The extension.js inside had its logic replaced with collection-and-transmit code.

The squatted namespaces read like a who’s-who of names developers trust on sight: AMD, Azure, Salesforce OSS, Hyperledger, IOTA, Artsy, LEGO Education, a US government agency namespace (ssagov), and — the boldest one — marketplace.visualstudio, impersonating the marketplace itself.

All 77 extensions reported to infrastructure under one domain: mangorbit[.]com. Most samples contacted pulse.mangorbit.com or pulse2.mangorbit.com; others used api.mangorbit.com or randomized subdomains under cb.mangorbit.com. The domain was registered on July 15, 2026 — 11 days before the first package appeared, which tells you this was planned infrastructure, not an opportunist with a free weekend. The malware even shipped a contingency: if the primary domain gets blocked or seized, it queries a DNS TXT record to fetch a fallback exfiltration URL. That is professional tradecraft in what looks, on the surface, like low-effort typosquatting.

Open VSX removed all 77 packages on August 3, 2026. Neither Manifold nor Open VSX has published install counts for this campaign, so nobody outside those teams knows how many machines actually ran the payloads — treat “unknown” as the honest answer, not “small.”

The 58/19 split: what data actually left

The 77 extensions were not equally dangerous, and the split matters for deciding how hard to respond.

The 58 lightweight variants collected little more than a fingerprint: the machine’s hostname, in some cases the workspace folder name and editor version, plus two quieter items that deserve more attention than they got — an enumeration of up to 60 installed extension IDs and the proxy hostname from your environment. The extension list alone tells an attacker which tools (and which attack surfaces) you run; the proxy hostname leaks a piece of your corporate network topology.

The 19 aggressive variants did real reconnaissance of your development context. Per Manifold’s analysis, they inspected the workspace’s .git directory and environment to collect:

• The host and organization from origin and upstream remote URLs — enough to know your employer and which private repos you touch
• The domain of your configured commit email
• Your current branch and HEAD commit SHA
• CI/cloud environment markers for GitHub Actions, GitLab CI, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces, and Gitpod — including the values of GITHUB_REPOSITORY, CI_PROJECT_PATH, the Azure DevOps collection URI, the Buildkite org slug, the CircleCI project username, the Codespace name, and the Gitpod workspace context URL

Now the calibration, because it changes what you need to do: Manifold found no code that accessed source code, credentials, authentication tokens, SSH material, or browser data. This was mapping, not looting. If one of the 19 ran on your machine, your secrets did not leave through it — but a detailed profile of where your secrets live did. That profile is exactly what a follow-up attack (a targeted phish against your GitLab instance, a poisoned dependency aimed at your org) is built from.

Who is exposed: the marketplace map

The single most misunderstood fact in this story is which editors actually use Open VSX. Microsoft’s terms restrict the official VS Code Marketplace to Microsoft’s own products, so every VS Code fork defaults to Open VSX — including tools whose users assume they’re on Microsoft’s infrastructure.

Editor	Extension source	Exposure to this campaign
Windsurf	Open VSX (its marketplace is an Open VSX front end)	Direct — Open VSX is the only built-in source
Cursor	Open VSX, via Cursor’s own proxy with malware scanning	Direct but filtered — Anysphere scans before offering installs
VSCodium	Open VSX by default	Direct
Gitpod / Coder / Trae	Open VSX	Direct
VS Code (official)	Microsoft Marketplace	None by default — only if you manually reconfigured to Open VSX
Cline / Continue.dev	These are extensions, not editors	Exposure follows whichever editor you installed them into

Two corrections to takes circulating on social media this week. First, “this is a Windsurf problem” undersells it: Cursor pulls third-party extensions from Open VSX too — Microsoft’s marketplace was never an option for either fork. Cursor’s proxy does apply automated malware and supply-chain analysis before offering extensions, which is a real mitigation layer Windsurf doesn’t advertise, but it is a filter on the same upstream source, not a different source. Second, “VS Code users are safe” is only true for defaults: plenty of developers pointed VS Code at Open VSX after Microsoft tightened marketplace access for forks, and those installs are just as exposed as a Windsurf machine.

If you followed our Continue.dev post-acquisition guide or run Cline inside a fork, this applies to you: the agent extension itself is fine, but it is sitting in an editor whose marketplace shipped 77 impostors for a week.

The five-minute audit

You are checking for three things: extensions installed from the campaign window, version-0.0.1 oddities, and publishers that don’t match the project they claim to be.

Step 1 — dump your installed extensions with versions. Every VS Code fork ships the same CLI flags under its own binary name (code, windsurf, cursor, codium):

$ windsurf --list-extensions --show-versions
# or: cursor --list-extensions --show-versions
# or: code --list-extensions --show-versions

codeium.codeium@<multi-digit version>
dbaeumer.vscode-eslint@<multi-digit version>
azure.<something>@0.0.1              ← this shape is the red flag
...

Your list will differ (versions above are placeholders). What you’re scanning for is the pattern in that third line: a trusted-sounding namespace at version 0.0.1. Real extensions from AMD, Azure, or Salesforce have years of version history; an impersonation republished in late July 2026 almost always sits at 0.0.1 because the attacker never bothered to fake a changelog.

Step 2 — check publishers against the source. For anything suspicious, open the extension’s page in your editor’s marketplace view and compare the publisher account and repository URL against the project’s known GitHub org. An “ESLint” extension whose repo link points anywhere but github.com/microsoft/vscode-eslint is not ESLint. This is tedious for a long list, so prioritize anything installed since July 26, 2026.

Step 3 — check for the beacon. If your machine or network keeps DNS logs, search them for mangorbit.com and its subdomains (pulse., pulse2., api., cb.). Any hit is confirmation an evil twin ran, and turns this from an audit into an incident. Block the domain at your resolver or firewall either way — the DNS TXT fallback means the operators planned for domain takedowns, but blocking the primary still cuts off every sample analyzed.

Step 4 — if you find one: remove, then assess, then (maybe) rotate. Uninstall the extension and reinstall from the verified publisher. If it was one of the 58 lightweight variants, what leaked was fingerprint data — annoying, not actionable. If your DNS logs show traffic and you work in one of the CI environments the 19 aggressive variants probed, the leaked repo and CI identifiers are targeting data: tell your security team, because the sensible defensive assumption is that your org is now on someone’s list. Token rotation isn’t strictly indicated by what this malware took — no tokens were accessed — but if you can’t determine which variant you ran, rotating CI tokens is the cheap conservative move.

Why this keeps happening to Open VSX

This is not Open VSX’s first bad year — it’s the third major incident in ten months, and the pattern is instructive.

In October 2025, Koi Security documented GlassWorm, the first self-propagating VS Code extension worm: compromised developer accounts, malicious code hidden in invisible Unicode characters, command-and-control over the Solana blockchain, and — unlike this month’s campaign — actual credential theft (npm, GitHub, Git, and Open VSX tokens) plus crypto-wallet draining. Seven Open VSX extensions were hit on October 17, 2025, with a reported 35,800 downloads (a figure the Open VSX team said was inflated by bot traffic). The Eclipse Foundation revoked leaked tokens and published a security update that month. GlassWorm then returned in December 2025 with 24 impersonation extensions, and by late January 2026 Socket had tied 72 more Open VSX extensions to the campaign — including some targeting Claude Code, Codex, and Antigravity users specifically.

The evil twin campaign is technically unrelated to GlassWorm but exploits the same structural gap: Open VSX does not verify namespace ownership the way developers assume. An arbitrary account was able to publish under AMD, Azure, and marketplace.visualstudio — names that on Microsoft’s marketplace carry verified-publisher checkmarks backed by domain verification. Open VSX is run by a small Eclipse Foundation team doing genuinely important work (without it, no VS Code fork could exist), but it processes publisher signups at open-source-foundation staffing levels while serving an ecosystem of tens of millions of fork users. Attackers have noticed the asymmetry. Three campaigns in ten months is not bad luck; it is the market price of that gap, and campaigns escalate — GlassWorm stole credentials, the evil twins built targeting maps, and whatever comes next gets to use both playbooks.

This is also the fifth entry in our 2026 series on AI-coding-tool trust boundaries, and the pattern across them is worth naming: agentjacking poisoned what the agent reads, GhostApproval abused what it writes, MemGhost corrupted what it remembers, the Kiro prompt injection weaponized its config, and this campaign never touched the AI at all — it walked in through the marketplace the editor was built on. Your agentic IDE’s security is the minimum of all five layers.

What to change permanently

Prefer the higher-scrutiny source when you have one. On official VS Code, stay on the Microsoft Marketplace. On Cursor, the built-in proxy scanning is a reason to install through the UI rather than sideloading VSIX files. On Windsurf and VSCodium, you don’t get a choice of source — so you become the verification layer.

Treat extension installs like dependency adds. You (hopefully) wouldn’t npm install a package with 12 downloads and no history because its name looked right. Apply the same bar: check the publisher, the version history, and the repo link before installing. Version 0.0.1 + famous namespace + recent upload date is the evil-twin signature.

Minimize the extension surface on machines that touch production. Every extension runs with your user’s privileges inside a process that has your repos, your env vars, and your network. The 19 aggressive variants needed zero exploits — installed extensions are simply allowed to read .git and environment variables. Fewer extensions, fewer publishers trusted, less to audit next time. If your threat model is strict enough that marketplace risk is unacceptable, the endpoint is a fully local, auditable stack — pair a FOSS editor setup from aifoss.dev with a local model backend sized per runaihome.com’s VRAM guide, and your coding assistant stops depending on anyone’s marketplace hygiene.

Alert on weird DNS from developer machines. Every sample in this campaign was loud at the network layer: fresh domain, odd subdomains, TXT-record lookups for fallback URLs. A resolver that flags newly registered domains would have caught this on day one — eleven days after registration, mangorbit.com was about as new as domains get.

FAQ

How do I know if I installed one of the 77? Cross-check anything you installed between July 26 and August 3, 2026, especially extensions at version 0.0.1 under big-name namespaces (AMD, Azure, Salesforce OSS, Hyperledger, IOTA, Artsy, LEGO Education, ssagov, marketplace.visualstudio). Manifold Security’s write-up carries the indicator details; a DNS-log search for mangorbit.com is the definitive local check.

Were any AI coding extensions impersonated? The confirmed namespace list for this campaign centers on vendor and platform tooling, not AI assistants. But the adjacent GlassWorm campaign explicitly shipped extensions targeting Claude Code, Codex, and Antigravity users, so “attackers ignore AI tooling” is not a safe assumption — it’s already false.

Do I need to rotate my GitHub/CI tokens? Not based on what this malware did — Manifold found no token or credential access. Rotate if you have DNS-log evidence a variant ran and you can’t determine which one, or if your security policy treats any confirmed malware execution as a rotation event (most do).

Is Windsurf less safe than Cursor now? For this specific vector, Cursor’s marketplace proxy adds a scanning layer Windsurf doesn’t document, so Cursor users had a better chance of the impostors being filtered. Both pull from the same upstream Open VSX registry. Our Windsurf review and Cursor review cover the broader trade-offs.

Should I stop using Open VSX entirely? If you use any VS Code fork, you can’t — it’s the only marketplace those editors have. The realistic posture is verification discipline on installs plus network-level monitoring, not abstinence.

Sources

• 77 “evil twin” Open VSX extensions: 19 copy private repo and CI data to a new domain — Manifold Security
• Open VSX Removes 77 Malicious Evil Twin Extensions Exfiltrating Developer Data — The Hacker News
• 77 Open VSX extensions found harvesting developer info — BleepingComputer
• 77 malicious extensions found on Open VSX marketplace — SC Media
• 77 Evil Twin Open VSX Extensions Exfiltrate Private Git Repository and CI Data — CybersecurityNews
• Fake Open VSX Extensions Harvest Private Repo and CI Data — Infosecurity Magazine
• Fake Open VSX Extensions Hijack AMD, Azure, Salesforce and Government Namespaces — GBHackers
• Extensions — Cursor Docs (Open VSX sourcing and proxy scanning)
• Marketplace takeover: how we could’ve taken over every developer using a VS Code fork — Koi Security
• GlassWorm: first self-propagating worm hits the Open VSX marketplace — Koi Security
• 72 Malicious Open VSX Extensions Linked to GlassWorm Campaign — Socket
• Open VSX security update, October 2025 — Eclipse Foundation

Last verified August 14, 2026. Marketplace policies and incident details change; check the primary sources before acting on security-critical specifics.