Уязвимость «воскрешения расширений» в Visual Studio Code и Open VSX позволила злоумышленникам внедрять вредоносный код через доверенные пакеты

Software developers routinely rely on automation to assemble their development environments. Extension packs are designed to make that process easier, allowing users to install collections of tools without individually selecting every component. But research from Bloom Security suggests that the convenience can also create a blind spot: developers may trust what they see while their IDE installs considerably more than they realize. Bloom Security discovered a vulnerability affecting extension packs on Microsoft’s Visual Studio Code Marketplace and the Eclipse Foundation’s Open VSX marketplace. The flaw allowed attackers to revive extensions that were referenced by existing packs but did not actually exist on the marketplace, effectively turning abandoned dependency slots into potential delivery mechanisms for malicious code. Bloom named the technique “Extension Resurrection” and found more than 750 affected packs with a combined download count exceeding 500,000. The issue has since been addressed following responsible disclosure to Open VSX and Microsoft. Trust Gets Inherited The fundamental problem lies in how extension packs establish trust. A developer may review a pack and decide it is legitimate, but the pack can contain numerous other extensions that receive access to the developer’s machine once installed. Bloom’s research found that some packs contained references to extensions that were missing from the marketplace. This could happen when an extension was never published to the marketplace, when marketplace content was mirrored incompletely, or when an existing extension was subsequently deleted. Bloom describes these missing references as “Shadow Dependencies.” They represent what should be an empty space in the marketplace, but the research showed that attackers could potentially turn that empty space into an active dependency. The distinction matters because extension packs identify bundled extensions by their publisher or namespace and extension ID rather than permanently pinning them to a specific version. If someone could claim an otherwise unregistered namespace and publish an extension matching the expected identity, the pack could resolve the previously nonexistent dependency. From Phantom Entry To Malicious Installation Bloom tested the theory on both marketplaces. On Open VSX, researchers attempted to recreate the prettify-json extension under the mohsen1 namespace. The marketplace initially rejected the exact version because its internal index retained a reference to the extension, despite the extension itself never having been published. Changing the version number provided a workaround. Bloom was then able to publish the extension, causing the dependency inside the existing pack to resolve to the newly uploaded version. The significance was the lack of an additional user decision. When the trusted pack was installed, the newly published extension was installed with it. Developers who had installed the pack earlier could also be exposed through subsequent updates because bundled extensions inherit the pack’s automatic update behavior. That creates a particularly unusual supply-chain scenario: the attacker does not necessarily need to compromise the developer who created the trusted pack or the marketplace account associated with an existing extension. Instead, the attacker takes advantage of an unresolved dependency that the marketplace itself has allowed to persist. Why Developer Machines Matter Bloom argues that the consequences are amplified by the privileges granted to IDE extensions. VS Code extensions and extensions for compatible IDEs such as Cursor, Kiro, Windsurf, Antigravity, VSCodium and Eclipse Theia run with Node.js host access. According to Bloom, those capabilities allow extensions to read and write files, spawn child processes and make outbound network requests. As a result, the company considers malicious extension installation functionally equivalent to remote code execution on the developer’s machine. The potential reach was also substantial. Bloom’s scan identified 94 of 321 Open VSX extension packs containing at least one shadow dependency, while 677 of 4,179 packs on the VS Code Marketplace contained one. Across the vulnerable packs, the combined download count exceeded 500,000. A Marketplace Problem With an Enterprise Lesson Bloom’s findings ultimately point beyond IDEs. Modern development environments increasingly depend on automated packages, plugins, extensions and AI-enabled tools, making the distinction between what users intentionally install and what software installs on their behalf increasingly important. The company identified two marketplace-level weaknesses behind the attack: insufficient validation of bundled extensions and dependencies, and the ability to register namespaces referenced by existing software. Open VSX responded after Bloom’s February 5, 2026 disclosure by assigning at-risk namespaces to the open-vsx account and implementing checks against nonexistent bundled extensions and dependencies. Microsoft was notified on February 17, 2026, and subsequently confirmed that protections against extension resurrection had been implemented in stages, with user-action protection completed in June 2026. For organizations, Bloom’s recommendation is straightforward: visibility into developer endpoints needs to extend beyond applications and operating systems. Security teams should know which extensions and packs are installed, how they are configured, whether automatic updates are enabled, and what capabilities each extension introduces. The larger lesson is that a trusted installation is not necessarily a fixed installation. In an ecosystem built around automatic dependency resolution and updates, what a developer approved yesterday may not be exactly what runs on the machine tomorrow.