TL;DR
Bloom Security’s “Extension Resurrection” research found that legitimate VS Code and Open VSX extension packs can reference extensions that don’t exist on the marketplace. Attackers could claim those namespaces and publish malicious extensions that install automatically through trusted packs. 677 of 4,179 VS Code packs and 94 of 321 Open VSX packs were vulnerable, with 500,000+ combined downloads. Both Microsoft and the Eclipse Foundation have since implemented protections after Bloom’s disclosure.
Security teams have spent years scrutinizing software dependencies, package repositories and build pipelines. Bloom Security‘s latest research suggests that another part of the software supply chain deserves closer attention: the extensions developers install inside their IDEs.
The company’s “Extension Resurrection” research examined extension packs on the Visual Studio Code Marketplace and Open VSX. Bloom found that legitimate packs could contain references to extensions that did not actually exist on the marketplace, creating an opportunity for attackers to claim those unused namespaces and publish malicious extensions under them.
The research identified 94 of 321 Open VSX extension packs with at least one “Shadow Dependency.” On the VS Code Marketplace, Bloom found 677 of 4,179 packs with at least one such dependency. Across the vulnerable packs, downloads exceeded 500,000.
The Real Issue Is the Trust Model
What makes the finding notable is that the attack does not depend on convincing a developer to install an unfamiliar extension. The developer has already made a trust decision by installing a legitimate extension pack.
That decision can extend to multiple dependencies that the user may never examine individually. Bloom’s research shows how a missing extension inside that chain can become an opportunity if the marketplace continues to recognize its identity while allowing someone else to register the corresponding namespace.
The result is a disconnect between what developers believe they have approved and what their development environment can ultimately install.
Automation Makes the Problem Bigger
Bloom’s research also highlights the role of automatic updates. Extension packs do not pin their bundled extensions to specific versions, meaning a pack installed in the past can potentially acquire a newly published version of a previously missing dependency.
That changes the nature of the risk. An organization does not necessarily need to install a malicious extension today to become exposed. A developer could have installed a legitimate pack weeks, months or even years earlier and later receive an extension through the pack’s update mechanism.
Bloom found that the combined download count for vulnerable packs exceeded 500,000, illustrating the potential scale of the exposure.
The technical impact is also significant. According to Bloom, VS Code extensions and extensions for compatible IDEs such as Cursor, Kiro, Windsurf, Antigravity, VSCodium and Eclipse Theia run with Node.js host access. They can read and write files, spawn child processes and make outbound network requests.
A Marketplace Design Problem
Bloom’s findings ultimately point to weaknesses in how marketplaces handled dependencies and namespaces.
The company identified two gaps: marketplaces could accept packs containing references to extensions that did not exist, and namespaces referenced by existing software could remain available for registration. Together, those conditions created a path for an attacker to turn a dormant reference into an active dependency.
The issue was not limited entirely to extension packs. During its investigation, Bloom found that Open VSX extension dependencies declared in manifests could be exposed to the same underlying problem.
Both marketplace operators responded after disclosure. Bloom reported the Open VSX issue to the Eclipse Foundation on February 5, 2026, and said the team moved quickly to protect at-risk namespaces and implement checks for nonexistent extensions and dependencies.
Bloom reported the issue to Microsoft on February 17. Microsoft initially rated it Moderate before reopening the case after Bloom provided additional evidence. Microsoft subsequently confirmed that protections against extension resurrection had been implemented in stages, with administrator-action protections dating to October 2025 and user-action protections completed in June 2026.
What the Research Means for Security Teams
The broader lesson from Bloom’s research is less about one specific marketplace vulnerability and more about how organizations think about developer endpoints.
IDE extensions are often treated as productivity tools rather than software components requiring continuous security oversight. Yet they can have deep access to the systems on which developers work, and extension packs can multiply the number of components introduced through a single installation.
For security teams, that means visibility should extend to installed extensions and packs, their configurations, automatic-update behavior and the capabilities of individual extensions. It also means recognizing that a trusted installation is not necessarily a permanent snapshot of what is running on an endpoint.
Bloom’s research demonstrates how a seemingly minor gap, a dependency that points to something that does not exist, can become a meaningful supply-chain security issue when combined with automated installation and updates.
The important question for organizations may therefore not be simply which extensions developers have approved, but which extensions their development environments are capable of installing without asking again.
