Dependency confusion moves into the editor: extension packs that point at nothing

Bloom Security has published research it calls "Extension Resurrection" showing that legitimate extension packs on the Visual Studio Code Marketplace and Open VSX can declare dependencies that do not exist on the marketplace, leaving the namespace free for someone else to register and publish under ^[1][2]. That matters because the install is automatic: the developer made one trust decision, at the pack, and the pack pulls whatever later occupies the empty slot ^[3].

The counts: 677 of 4,179 VS Code packs and 94 of 321 Open VSX packs carried at least one of what Bloom calls a Shadow Dependency ^[4][5]. That is roughly 16 percent of VS Code packs and 29 percent of Open VSX packs, 771 of 4,500 in total ^[1][2][3]. Combined downloads across the vulnerable packs exceeded 500,000 ^[6], which averages to at least about 650 downloads per affected pack ^[4]. This is a long tail, not a handful of fat targets.

The mechanism is the one build engineers learned to fear from package registries, relocated one layer up into the IDE. Two conditions had to hold at once, according to Bloom: marketplaces accepted packs referencing extensions that did not exist, and namespaces referenced by existing software remained available for registration ^[7]. Packs do not pin their bundled extensions to specific versions ^[8], so a pack installed weeks, months or years ago can acquire a newly published version of a previously missing dependency through the update path ^[9]. Nothing has to be installed today for an organisation to be exposed.

What would run is not sandboxed script. Bloom says VS Code extensions, and extensions on compatible IDEs including Cursor, Kiro, Windsurf, Antigravity, VSCodium and Eclipse Theia, run with Node.js host access ^[10], meaning they can read and write files, spawn child processes and make outbound network requests ^[11]. That is the same authority as the developer running the editor.

On disclosure: Bloom reported the Open VSX issue to the Eclipse Foundation on February 5, 2026, and says the team moved quickly to protect at-risk namespaces and add checks for nonexistent extensions and dependencies ^[12]. Bloom reported to Microsoft on February 17 ^[13]. Microsoft initially rated it Moderate and reopened the case after Bloom supplied more evidence ^[14], then confirmed protections were implemented in stages, with administrator-action protections dating to October 2025 and user-action protections completed in June 2026 ^[15]. Read the dates carefully: the administrator-side control predates Bloom's report by about four months ^[5], and the user-side work finished roughly four months after it ^[6]. The severity argument, not the engineering, appears to have been the slow part.

The scope also is not limited to packs. During the investigation Bloom found that Open VSX extension dependencies declared in manifests could be exposed to the same underlying problem ^[16].

Worth watching: whether either marketplace now rejects a pack at publish time when a referenced extension is missing, and whether referenced namespaces are permanently reserved rather than merely protected while at risk ^[7]. For anyone running an editor fleet, the practical question is inventory. A pack installed years ago is a standing grant of install permission ^[9], and none of the vendor fixes retroactively tell you which of your machines took delivery.