By ByteBot
Between July 26 and August 1, 2026, an attacker published 77 fake extensions to the Open VSX Registry — the extension marketplace powering VS Codium, Gitpod, Eclipse Theia, and most devcontainer-based setups. Each one cloned the name and namespace of a legitimate extension, funneled collected data to a freshly registered domain, and waited. Manifold Security caught it. The Eclipse Foundation pulled all 77 by August 3. But the extensions are gone from the registry, not from machines and containers that already installed them. If you run anything outside vanilla VS Code, check your installs now.
Automated Installs Are the Real Problem
The surface-level story is 77 malicious extensions. The real story is how they spread: not through user error, but through infrastructure automation.
Modern developer setups install extensions automatically. Your devcontainer.json specifies which extensions to install when a container boots. Your team’s provisioning scripts install whatever the config lists. CI pipelines spin up editor environments with extensions baked in. All of these install by extension ID — not by verified publisher identity. There is no ownership check. There is no “is this the same publisher as last time?” The name matches, it installs.
Manifold Security put it directly: “Extension installation is increasingly automated, with devcontainer configurations, editor setup scripts, and provisioning workflows installing extensions by name without checking publisher ownership, download history, or project lineage.”
That is the architectural problem. This particular campaign just exploited it.
What the Extensions Actually Collected
The 77 extensions split into two tiers. Fifty-eight collected basic system information: hostname, username, operating system. Noisy, useful for fingerprinting, but relatively limited.
The remaining 19 ran a more detailed reconnaissance routine. They collected:
- Git remote host and organization
- Commit email domain
- Workspace path and branch name
- HEAD commit hash
- CI project identifiers and CI system in use
That combination is enough to map an organization’s infrastructure without touching a single line of source code. You know where their repos live, who works there (via email domains), what their branching strategy looks like, and what CI systems they run. Source code, credentials, SSH keys, and authentication tokens were not accessed — but the reconnaissance data is more than enough for targeted follow-up attacks.
The brazen detail: the 19 high-recon extensions listed their telemetry fields openly in their Open VSX listing, under a “Telemetry” section. They were not hiding what they collected. The data collection was architectural, not covert.
A Pre-Planned Campaign Against Trusted Namespaces
This was not opportunistic. The command-and-control domain, mangorbit[.]com, was registered on July 15 — eleven days before the first extensions appeared. All 77 packages routed to the same domain. The operation had infrastructure standing by before a single extension was published.
The namespace targets were not random: AMD, Azure, Salesforce, Hyperledger, and at least one U.S. government agency namespace were impersonated. High-trust, high-recognition names that automated tooling would not question. Every fake extension was published at version 0.0.1 from pseudonymous accounts with no prior publishing history. The only signal of legitimacy was the name match. For automated installation workflows, that was enough.
Why Open VSX Keeps Getting Hit
Open VSX is the extension registry for editors that cannot access Microsoft’s proprietary VS Code Marketplace. VS Codium, Eclipse Theia, Gitpod, and most AI-assisted VS Code forks — Cursor, Windsurf, Google Antigravity — all rely on it. That means it is embedded in devcontainer configs across thousands of teams.
The trust infrastructure lags significantly behind the VS Code Marketplace. Wiz’s analysis of VSCode extension marketplace supply chain risk documents the gap: Microsoft’s registry signs extensions at publish time, runs secrets scanning, enforces verified publisher badges with domain verification, and blocks extensions with detected secrets before they go live. Open VSX introduced pre-publish security checks in February 2026 — similarity detection, malware scanning, secrets scanning. This campaign bypassed all of it.
This is the third significant extension marketplace attack in 2026. In May, a malicious update to the Nx Console extension — 2.2 million installs — was live for 11 to 18 minutes and exfiltrated approximately 3,800 internal GitHub repositories. In January, attackers registered unclaimed Open VSX namespaces for extensions that AI-powered forks still recommended by default. The direction of travel is clear.
Three Things to Do Now
The extensions are off the registry. They are not off your machines or your containers.
- Audit your config files. Search for extension IDs from Manifold Security’s published list in your
.vscode/extensions.json,.devcontainer/devcontainer.json, and.devcontainer.json. Check developer and CI images too. - Block mangorbit[.]com. If any of the 77 extensions were installed before August 3, data may have been sent already. Blocking the domain prevents any further communication from extensions still installed locally.
- Treat unverified-publisher warnings as blocking conditions. Open VSX shows an unverified-publisher banner on extensions without confirmed publisher identity. In automated installs this banner is invisible. Change your policy: if a publisher is unverified, the automated install should not proceed.
The underlying issue is not this campaign — it is that the trust model for automated extension installation does not match the risk. Extensions have deep access to your editor environment. Automated installs do not ask permission. Until Open VSX closes the publisher verification gap that the VS Code Marketplace has spent years building, the risk is structural, and periodic auditing is the only real mitigation available to developers right now.
