Bloom Security has disclosed a supply chain vulnerability affecting the two largest distribution points for IDE extensions, allowing an attacker to seize control of extensions that trusted bundles already referenced but that no longer existed. The company calls the technique Extension Resurrection. It touched more than 750 extension packs and over half a million downloads across Open VSX and the Visual Studio Code Marketplace. Both operators have acknowledged the issue and shipped fixes.
The finding began as a routine data quality check. It ended as a demonstration that a developer could install a curated, reputable extension pack and silently receive attacker-controlled code alongside it, with no separate prompt and no additional click.
The Mechanics of an Empty Seat
Extension packs are curated bundles. A developer installs one pack and receives a linter, a formatter, a debugger, and a test runner in a single action. The convenience is the point. The pack is reviewed. The individual components inside it usually are not.
Bloom Security’s researchers found that both marketplaces accepted packs referencing extensions that did not exist. The company labels these dangling entries Shadow Dependencies. Two conditions produce them. In the first, a pack gets mirrored from the VS Code Marketplace to Open VSX while one or more of its bundled extensions does not make the trip. In the second, an extension that a live pack references is simply deleted.
Either way, the manifest keeps pointing at a name with nothing behind it. As the writeup puts it, an empty seat at the table. A name without a face.
Claiming that seat proved straightforward. The VS Code Marketplace identifies extensions as <publisher>.<extension_id>. Open VSX uses <namespace>.<extension_id>. Taking over a removed extension therefore requires registering under the original publisher or namespace, not just the extension ID. On both platforms, that registration was open to anyone.
Scanning Produced Hard Numbers
Bloom Security mapped every extension pack against the actual existence of its bundled components.
On Open VSX, 94 of 321 extension packs contained at least one shadow dependency where the namespace was not registered. On the VS Code Marketplace, 677 of 4,179 extension packs contained at least one shadow dependency, with 60 of those tied to a publisher that had never been registered.
The team then tested the hypothesis with two live examples: the prettify-json extension under the mohsen1 namespace on Open VSX, and control-snippets under the svipas publisher on the VS Code Marketplace. Both were bundled by pre-existing packs. Neither was present on its marketplace.
A Rejection That Confirmed the Theory
The first upload attempt on Open VSX failed. The researchers had tried to publish an exact version match, and the marketplace refused it.
The refusal was the tell. Open VSX already held an internal pointer to the extension, a ghost record inherited from the mirrored pack’s manifest, even though the extension itself had never been published. The index knew about something that did not exist.
Bumping the version number defeated it. Extension packs do not pin to specific versions of the extensions they bundle. They reference by ID alone, because centralized management of a bundle would make little sense if every component demanded individual updates. A newer version satisfied the dependency exactly as the original would have. The extension published successfully. The pack’s bundled link resolved to code under Bloom Security’s control almost immediately.
The Exposure Extends Backward in Time
New installs were only part of the problem. Because packs lack version pinning, auto-update settings for bundled extensions are inherited from the pack’s own configuration, and the default enables auto-updates.
That means a developer who installed a pack weeks, months, or years earlier under default settings could pull in a hijacked extension on the next IDE update cycle without ever returning to the marketplace.
VS Code extensions, along with extensions for compatible IDEs including Cursor, Kiro, Windsurf, Antigravity, VSCodium, and Eclipse Theia, run with Node.js host access. They read and write files. They spawn child processes. They make outbound network requests. Bloom Security notes that an extension is not sandboxed in any meaningful sense where code execution is concerned, which makes installing a malicious one functionally equivalent to remote code execution on the developer’s machine.
Applying what the company describes as a very conservative assumption, that half of the affected downloads had auto-update enabled, the research puts the reachable population at a quarter of a million compromised developer endpoints within 24 hours.
Two Vendors, Two Response Curves
Bloom Security reported the vulnerability to the Eclipse Foundation’s Open VSX team on February 5, 2026. The company describes the response as immediate and professional. Eclipse assigned all at-risk namespaces to the open-vsx account within hours, cutting off the registration path, then committed to blocking creation of packs referencing non-existent bundled extensions and extensions declaring non-existent dependencies. That pre-publication check is now implemented and enforced. During triage, Open VSX also confirmed that extension dependencies, not just packs, carried the identical flaw.
Microsoft received the report through MSRC on February 17, 2026, with a full proof of concept and video demonstration. Its first assessment landed at Moderate severity: “After careful investigation, this case has been assessed as Moderate severity and does not meet Microsoft’s bar for immediate servicing as Visual Studio Marketplace has existing publisher resurrection prevention…”
Bloom Security pushed back with the video evidence and further examples of re-registering removed publishers. Microsoft reopened the case and, after engineering review, confirmed that a fix had been partially released in October, that the extension resurrection prevention had covered admin actions since October, and that coverage for user actions arrived only in the month of that response. The staged rollout ran from admin actions in October 2025 to user actions in June 2026, documented in the VS Marketplace public discussion at github.com/microsoft/vsmarketplace/discussions/1708. Microsoft acknowledged that the user-action portion completed after the report was filed. The gap between the two stages left genuine exposure, which Bloom Security demonstrated.
What Security Teams Are Being Asked to Do
The recommendations are unglamorous and specific. Know which extensions and packs are installed across the organization. Know whether auto-update is enabled, and for what. Determine whether policy restricts extensions to a pre-approved list. Audit the capabilities and security posture of every installed extension, continuously, for every new version.
Bloom Security frames extensions as one instance of a larger governance gap on the endpoint, where installs, updates, configurations, and AI tooling introduce new dependencies daily. The company has published a detection script for identifying affected packs locally, along with tables of the impacted bundles on both marketplaces.
