Seventy-seven counterfeit extensions appeared on Open VSX between July 26 and Aug. 1, impersonating legitimate Visual Studio Code Marketplace tools while sending data to the same newly registered domain. Nineteen collected detailed information about developer machines, Git repositories, and CI/CD environments.
The extensions had been removed from Open VSX by Aug. 3, but copies already installed on developer machines or baked into development images can remain, while workspace configurations may continue to reference the affected package names. Automated provisioning increases the risk because Open VSX and Microsoft’s marketplace maintain separate publisher-ownership systems.
Manifold Security’s Aug. 4 investigation found that all 77 reused the identities and listing copy of legitimate VS Code Marketplace extensions while being distributed by accounts unaffiliated with the original publishers. Most used version 0.0.1, and all communicated with infrastructure under mangorbit[.]com.
Fifty-eight extensions sent relatively limited information, such as a hostname and, in some cases, the workspace folder or editor version. The other 19 collected OS usernames, workspace paths, Git organization and branch information, installed extension IDs, and CI identifiers. On some build runners and cloud development environments, those identifiers could reveal a private repository path.
Manifold found no source-code, credential, token, SSH-key, or browser-data theft in the analyzed packages. Researchers did find that some extension listings said CI values stayed on the machine even though the underlying code transmitted them.
The campaign follows a broader Open VSX provenance problem. In July, Pluto Security identified 150 squatted extension names that could resolve to packages published by unrelated accounts when developers migrated extensions to Open VSX-backed editors. Those samples were not actively malicious when analyzed, although many had been modified to execute whenever the editor started.
Developer tooling has faced other attack paths this summer. A June github.dev flaw could have exposed developer OAuth tokens, while a July Cursor vulnerability allowed a crafted repository to execute code on affected Windows systems.
Audit what actually reached the environment
Run code --list-extensions --show-versions to inventory installed extension IDs and versions; Microsoft documents the command in its VS Code command-line reference. Teams should also inspect .vscode/extensions.json, .devcontainer/devcontainer.json, .devcontainer.json, and developer or CI images because automated provisioning can install extensions without a developer manually selecting them.
A marketplace takedown does not remediate systems where an extension is already present. Teams investigating this campaign should check affected package IDs, review editor traffic involving mangorbit[.]com, and inspect endpoints or build environments where suspicious extensions ran.
Treat extensions as supply-chain dependencies
Organizations automating extension installs should reject packages from unverified Open VSX publishers, while internal mirrors should restrict approved packages to known publishers and versions.
Managed VS Code fleets can use Microsoft’s extensions.allowed policy to control permitted publishers, extensions, versions, and platforms. A recently patched TeamCity flaw likewise showed how compromised development systems can put connected CI/CD pipelines at risk.
Extension inventories, publisher verification, allowlists, and endpoint monitoring should be routine wherever developer systems can access source code, cloud resources, or deployment infrastructure.
Read more: Compromised developer devices can require remediation beyond one workstation: a recent OpenAI supply-chain incident led to broader certificate and application-security measures.
