Bloom Security's research on Extension Resurrection reveals a gap in developer security.

      TL;DR: Bloom Security's "Extension Resurrection" study revealed that legitimate VS Code and Open VSX extension packs can reference non-existent extensions in the marketplace. This vulnerability allows attackers to take over those namespaces and distribute malicious extensions that can be installed automatically through trusted packs. Of the 4,179 VS Code packs, 677 were vulnerable, along with 94 of 321 Open VSX packs, totaling over 500,000 downloads. In response to Bloom's findings, both Microsoft and the Eclipse Foundation have introduced protective measures.

      Security teams have long examined software dependencies, package repositories, and build pipelines. However, Bloom Security's latest research indicates that another aspect of the software supply chain, specifically the extensions used within developers' IDEs, needs more scrutiny.

      The "Extension Resurrection" study reviewed extension packs on the Visual Studio Code Marketplace and Open VSX. Bloom found that valid packs could reference extensions that do not actually exist in the marketplace, allowing attackers to claim these unlabeled namespaces and publish malicious extensions.

      The research noted that 94 out of 321 Open VSX extension packs had at least one "Shadow Dependency," while 677 out of 4,179 packs on the VS Code Marketplace had at least one such dependency. These vulnerable packs collectively had over 500,000 downloads.

      The Core Issue: Trust Model

      What makes this finding significant is that the attack does not rely on tricking a developer into installing a strange extension. The developer has already made a trust decision by opting for a legitimate extension pack. This trust extends to various dependencies that the user might never review individually. Bloom's research illustrates that the absence of a specific extension within that dependency chain could lead to exploitation if the marketplace continues to acknowledge that identity while permitting someone else to register the corresponding namespace.

      Consequently, there exists a disparity between what developers believe they have authorized and what their development environment could eventually install.

      The Problem is Exacerbated by Automation

      Bloom's research also sheds light on the complications posed by automatic updates. Extension packs do not lock their bundled extensions to specific versions, which means that a pack installed in the past could potentially adopt a newly released version of a previously absent dependency.

      This alters the risk dynamics. An organization need not install a malicious extension today to be vulnerable; a developer might have installed a legitimate pack weeks, months, or even years ago and later receive a harmful extension through the pack's update process.

      Bloom noted that the total download count for vulnerable packs surpassed 500,000, highlighting the potential extent of the risk.

      The technical implications are substantial. According to Bloom, VS Code extensions and those for compatible IDEs like Cursor, Kiro, Windsurf, Antigravity, VSCodium, and Eclipse Theia operate with Node.js host access, allowing them to read and write files, spawn child processes, and make outbound network requests.

      A Marketplace Design Flaw

      Bloom's findings ultimately highlight the shortcomings in how marketplaces handle dependencies and namespaces. The study identified two critical weaknesses: marketplaces can accept packs that contain references to non-existent extensions, and namespaces linked to existing software can remain available for registration. These conditions collectively enable an attacker to convert an inactive reference into a functional dependency.

      This issue isn't confined solely to extension packs. During its inquiry, Bloom discovered that Open VSX extension dependencies declared in manifests could be susceptible to the same root problem.

      Following the disclosure, both marketplace operators responded. Bloom reported the Open VSX issue to the Eclipse Foundation on February 5, 2026, and they promptly took steps to safeguard vulnerable namespaces and instituted checks for non-existent extensions and dependencies.

      Bloom reported the problem to Microsoft on February 17. Initially rated as Moderate, Microsoft reopened the case after additional evidence was presented by Bloom, confirming that measures against extension resurrection were gradually implemented, with protections against administrator actions starting in October 2025 and user-action protections finalized in June 2026.

      Implications for Security Teams

      The broader takeaway from Bloom's research emphasizes not just one specific marketplace vulnerability but how organizations should consider developer endpoints. IDE extensions are frequently seen as productivity tools, rather than software components that require ongoing security monitoring. However, they can gain deep access to developers' systems, and extension packs can significantly increase the number of components introduced through a single installation.

      For security teams, this means ensuring visibility into installed extensions and packs, their configurations, automatic update behaviors, and the functionalities of individual extensions. It also entails realizing that a trusted installation is not necessarily a fixed representation of what is operating on an endpoint.

      Bloom's research illustrates how a seemingly minor issue—a dependency that refers to a non-existent component—can evolve into a significant supply chain security risk when coupled with automated installations and updates.

      Thus, a critical question for organizations may not simply be which extensions developers have approved, but rather which extensions their development environments can install autonomously without seeking further consent.