Developer environments are becoming increasingly dependent on extensions, plugins and automated tools, creating new opportunities for supply-chain attacks that do not necessarily involve compromised software publishers. Bloom Security has uncovered one such weakness affecting extension packs on Microsoft’s Visual Studio Code Marketplace and the Eclipse Foundation’s Open VSX marketplace.
The company calls the technique “Extension Resurrection.” Its research found that attackers could potentially claim namespaces associated with nonexistent extensions referenced by legitimate extension packs, publish malicious code under those identities and have the extension installed automatically alongside the trusted bundle.
Bloom identified more than 750 affected extension packs across the two marketplaces, with a combined download count exceeding 500,000. Both Open VSX and Microsoft acknowledged and patched the vulnerability following Bloom’s disclosures.
The Trust Problem
Extension packs are designed to make development environments easier to configure. Rather than installing individual tools one at a time, a developer can install a pack containing multiple extensions for tasks such as formatting, debugging and testing.
The security issue arises because the developer is effectively trusting the entire bundle. Bloom found that some packs contained references to extensions that did not exist on the relevant marketplace. The company calls these references “Shadow Dependencies.”
The condition could occur when a pack was mirrored between marketplaces but one of its bundled extensions was not, or when an extension referenced by an existing pack was deleted. The pack retained the reference even though the extension itself was absent.
Bloom investigated whether an attacker could fill those empty slots.
Claiming the Missing Extension
Researchers scanned extension packs on both marketplaces. On Open VSX, they found 94 of 321 packs containing at least one shadow dependency. On the VS Code Marketplace, 677 of 4,179 packs contained at least one.
Bloom also found that 60 of the affected VS Code Marketplace packs referenced a shadow dependency associated with a publisher that was not registered.
The researchers then tested whether they could recreate missing extensions. One Open VSX test involved prettify-json under the mohsen1 namespace. The marketplace initially rejected the attempt because its internal index retained a reference to the extension, even though the extension had never been published.
Bloom discovered that increasing the version number allowed the extension to be published. Because extension packs reference bundled extensions by ID rather than pinning them to specific versions, the newly published extension could satisfy the dependency.
That meant a developer installing the original trusted pack could receive the newly published extension without selecting it separately.
Automatic Updates Raised the Stakes
The problem did not necessarily stop with new installations. Bloom found that developers who had installed an affected pack weeks, months or even years earlier could potentially receive the malicious extension through an update.
Extension packs do not pin their bundled extensions to specific versions. Their automatic-update configuration is inherited by the extensions within the pack, with automatic updates enabled by default.
Bloom said the combined download count across vulnerable packs exceeded 500,000. The company also pointed to the privileges available to extensions running in VS Code and compatible IDEs such as Cursor, Kiro, Windsurf, Antigravity, VSCodium and Eclipse Theia.
These extensions run with Node.js host access and can read and write files, spawn child processes and make outbound network requests. Bloom therefore described a malicious extension installation as functionally equivalent to remote code execution on the developer's machine.
Closing the Gaps
Bloom identified two weaknesses behind the attack: marketplaces did not sufficiently verify that bundled extensions and declared dependencies actually existed, and namespaces referenced by existing software could remain available for registration.
The company disclosed the issue to Open VSX on February 5, 2026. The Eclipse Foundation responded by assigning at-risk namespaces to the open-vsx account and implementing checks preventing packs from referencing nonexistent extensions and dependencies.
Bloom reported the issue to Microsoft on February 17. Microsoft initially assessed it as Moderate before reopening the case after additional evidence was provided. Microsoft later confirmed that protections against extension resurrection had been introduced in stages, covering administrator actions in October 2025 and user actions in June 2026.
For organizations, Bloom’s research reinforces the need to treat developer tooling as part of the enterprise attack surface. Security teams should maintain visibility into installed extensions and packs, review their configurations and automatic-update settings, and continuously assess the capabilities and risks of the software running inside developer environments.
The central lesson is straightforward: trusting an extension pack also means trusting everything it can install later. In an environment where dependencies can change automatically, a one-time installation decision may not remain a one-time decision.
Written by the editorial team of TVC.
