The software supply chain is often associated with compromised packages, malicious maintainers and poisoned repositories. But a new finding from Bloom Security highlights a less obvious path into developer environments: extensions that were never supposed to exist in the first place.
Bloom discovered a vulnerability affecting extension packs on Microsoft’s Visual Studio Code Marketplace and the Eclipse Foundation’s Open VSX marketplace. The company found that these marketplaces could allow extension packs to reference nonexistent extensions, creating what it calls “Shadow Dependencies.” Attackers could potentially claim the unregistered namespaces associated with those references and publish malicious extensions under the expected identities.
Bloom dubbed the technique “Extension Resurrection.” Its investigation identified more than 750 affected extension packs, with the vulnerable packs accounting for more than 500,000 downloads.
Both Open VSX and Microsoft acknowledged and patched the issue following Bloom’s disclosures.
The Problem With One-Click Installation
Extension packs are intended to simplify the developer experience. Instead of finding and installing individual tools, developers can install a collection of related extensions through a single action.
That convenience also means users may not examine every component included in a pack. According to Bloom, the problem becomes more significant because extensions are granted substantial access to the host system, including the ability to interact with files, processes and networks.
Bloom’s research focused on what happens when a pack contains a reference to an extension that isn’t actually available on the marketplace. This can occur when an extension included in a mirrored pack was never mirrored itself or when an extension referenced by an existing pack was later deleted.
Those references can effectively leave an empty slot in a trusted bundle. Bloom’s researchers investigated whether someone else could fill that slot.
Turning an Empty Slot Into a Dependency
The company scanned the two marketplaces to identify extension packs with missing bundled extensions. On Open VSX, 94 of 321 extension packs contained at least one shadow dependency, while 677 of 4,179 packs on the VS Code Marketplace contained at least one.
Bloom found that 60 of the affected VS Code Marketplace packs contained shadow dependencies belonging to publishers that were not registered.
Researchers then tested whether they could recreate the missing extensions. One Open VSX example involved the prettify-json extension associated with the mohsen1 namespace. Bloom attempted to publish an extension using the same identity and version information.
The marketplace initially rejected the attempt because its index retained an internal reference to the extension, despite the extension never having 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. When the original pack was installed, the malicious extension was installed with it without requiring a separate user action.
Automatic Updates Extended the Risk
The attack also created a potential exposure path for developers who had installed affected packs in the past.
Bloom noted that extension packs do not pin their bundled extensions to particular versions. Instead, the automatic update configuration can be inherited by the extensions within the pack. With automatic updates enabled by default, a developer could install a legitimate pack and later receive a newly published extension without returning to the marketplace or explicitly selecting it.
Bloom said the combined download count for vulnerable packs across the two marketplaces exceeded 500,000.
The company also emphasized the sensitivity of developer endpoints. VS Code extensions and extensions for compatible IDEs, including 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.
Bloom therefore characterized installation of a malicious extension as functionally equivalent to remote code execution on the developer’s machine.
Fixing the Marketplace Weakness
Bloom identified two separate marketplace gaps that made the attack possible. Marketplaces did not adequately enforce the existence of bundled extensions and declared dependencies when packs were created, while namespaces could be registered even when they were referenced by existing software.
The company reported the Open VSX issue to the Eclipse Foundation on February 5, 2026. The team assigned at-risk namespaces to the open-vsx account and implemented checks preventing extension packs from being created with nonexistent bundled extensions or dependencies.
Bloom reported the issue to Microsoft through MSRC on February 17, 2026. Microsoft initially assessed the issue as Moderate before reopening the case after Bloom provided additional evidence. Microsoft subsequently confirmed that extension resurrection protections had been introduced in stages, with protections for administrator actions beginning in October 2025 and protections covering user actions arriving in June 2026.
The Broader Enterprise Lesson
For security teams, the research illustrates why developer tooling increasingly needs to be treated as part of the enterprise attack surface. Reviewing an extension pack by its name or publisher may not provide visibility into everything that will ultimately run on a workstation.
Bloom recommends that organizations maintain visibility into installed extensions and packs, IDE configurations and automatic-update settings, while continuously assessing the capabilities and security posture of extensions.
The issue also offers a lesson for marketplace operators. Validating that every bundled extension and declared dependency exists, while protecting namespaces referenced by published software, can prevent phantom references from becoming exploitable dependencies.
As development environments continue to incorporate more extensions, packages and automated tooling, the distinction between what a developer deliberately installs and what their environment installs on their behalf becomes increasingly important.
John Kevin Hao is a news and feature writer covering cybersecurity, technology, and business targeted for professional audiences.