Open VSX is not a niche project. It is the extension marketplace the Eclipse Foundation, based in Brussels, built specifically so that VS Code forks and EU public-sector deployments that cannot accept Microsoft’s Visual Studio Marketplace terms of use still have somewhere to get extensions. That makes its security posture a European infrastructure question, not just a developer-tooling footnote.
Same name, different publisher
Between 26 July and 1 August 2026, Manifold Security identified 77 extensions uploaded to Open VSX that reused the exact names, namespaces and descriptions of legitimate, well-known extensions, but were published from unrelated accounts. Most carried the low version number 0.0.1, a sign of freshly created listings rather than compromised existing ones. Researchers linked all 77 back to a single campaign through a shared data-exfiltration domain and matching code and network behaviour. The hijacked namespaces read like a who’s who of enterprise tooling: AMD, Artsy, LEGO Education, Hyperledger, Azure, IOTA, Salesforce OSS, a .gov agency namespace, and even a fake listing impersonating marketplace.visualstudio itself.
What actually left the machine
Fifty-eight of the extensions sent only lightweight telemetry, a hostname, sometimes a workspace folder name or editor version. The other 19 went considerably further, exfiltrating the machine description, the name of the repository open in the editor, and identifiers for whatever CI system the editor was running inside. Manifold reported that the extensions did not touch source code, credentials, tokens, SSH keys or browser data, which limits the immediate damage but does not eliminate it: private repository names, project paths and CI metadata are exactly the reconnaissance an attacker wants before a targeted phishing run or a follow-on supply chain intrusion. Open VSX pulled all 77 packages by 3 August, but removal from the registry does not remove an already-installed extension from a developer’s machine.
The fix that was supposed to prevent this
This is not Open VSX’s first brush with a marketplace-wide compromise. In February 2026, following the GlassWorm worm that abused dozens of Open VSX extensions to spread automatically, the Eclipse Foundation announced it would enforce security checks before extensions could be published, explicitly to stop this class of attack from recurring. Five months later, a campaign built entirely around namespace impersonation, a problem pre-publish review is meant to catch by definition, still made it onto the registry and stayed there for the better part of a week before anyone noticed. If your organisation treats “the platform added security checks” as the end of the conversation rather than the start of your own verification process, this is the reminder that vendor-side controls need testing, not trust.
If your development teams pull extensions from Open VSX or the VS Code Marketplace, particularly in CI pipelines where a compromised extension could see repository and build metadata, we can help you audit what is currently installed across your fleet and put a vetting process in place before the next evil twin campaign. Contact Excello Digital to talk through securing your developer tooling supply chain.
