The IDE extension ecosystem is split for reasons that have nothing to do with security.
Microsoft’s VS Code Marketplace terms explicitly forbid non-Microsoft products from connecting to it. That restriction left VSCodium, Eclipse Theia, Cursor, Windsurf, Kiro, and Antigravity without a first-party source for the tooling their users expect. Open VSX, an open-source and vendor-neutral marketplace under the Eclipse Foundation umbrella, exists to fill that gap.
Bloom Security‘s new research shows what happens when a licensing boundary becomes a data boundary. Content flows between the two ecosystems through mirroring. Mirroring is imperfect. And imperfect mirroring, the company found, produced a supply chain vulnerability spanning both marketplaces, touching more than 750 extension packs and over 500,000 downloads.
The Gap Mirroring Leaves Behind
Not every extension on the VS Code Marketplace makes it to Open VSX.
That creates a specific failure mode when a pack crosses over without all of its contents. The pack arrives with its manifest intact, listing bundled extensions that were never mirrored. Bloom Security calls the result a Shadow Dependency: a dangling reference inside a trusted bundle, aimed at an extension that does not exist on the marketplace.
A second, simpler route produces the same artifact. An extension gets deleted while a live pack still references it. The pointer outlives the target.
Both marketplaces accepted these packs without complaint. Neither validated that bundled extensions existed at submission time. Bloom Security names that missing dependency check as the root cause.
Registration Was the Second Half
Extensions carry a composite identity: publisher plus extension ID on the VS Code Marketplace, namespace plus extension ID on Open VSX. Resurrecting a removed extension therefore demands control of the original publisher or namespace, not just the ID.
On both platforms, that control was available for the asking. Namespaces and publishers were freely registerable regardless of whether published software already referenced them. No account needed compromising. An attacker claims an unclaimed name and publishes into it.
Bloom Security’s scan gave the exposure dimensions. Open VSX held 94 of 321 extension packs with at least one shadow dependency whose namespace nobody had registered. The VS Code Marketplace held 677 of 4,179 packs with at least one shadow dependency, 60 of them under an unregistered publisher.
Proof, and the Rejection That Preceded It
Two live examples served as tests. On Open VSX, prettify-json inside the mohsen1 namespace. On the VS Code Marketplace, control-snippets under the svipas publisher. Both bundled by pre-existing packs. Neither present on its marketplace.
The first attempt at publishing an exact version match on Open VSX was rejected, and the rejection message proved more useful than a success. The marketplace already held an internal pointer to the extension, a ghost record inherited from the mirrored pack’s manifest, and refused the version because the index treated it as existing.
Incrementing the version defeated the check. Packs reference bundled extensions by ID and do not pin versions, since requiring individual updates would undermine the centralized management that makes a pack useful. Any newer version satisfies the dependency. The extension published. The pack’s link resolved to it almost immediately.
The Growth Curve Behind the Numbers
Context matters for how quickly a flaw like this scales.
In the first six months of 2026 the VS Code Marketplace nearly doubled in size. Across both marketplaces, roughly 1,400 new extensions arrive daily. AI has let development teams move at a pace that produces an explosion of new software releases, and extension catalogs absorb that output directly.
More packs mean more manifests. More manifests mean more references. More references mean more opportunities for a pointer to outlive its target.
Cost Model for the Attacker
The economics here favor the attacker to an uncomfortable degree.
There is no phishing campaign to run. No registry to compromise. No convincing fake to build and market. The trusted bundle supplies the credibility, and the phantom namespace supplies the delivery. Bloom Security’s own framing of that dynamic appears in the writeup as a callout:
“The attacker doesn’t need to phish a developer, compromise a registry, or publish a convincing fake. The trusted bundle does the social engineering. The phantom namespace does the rest.”
Delivery reaches beyond new installs. Bundled extensions inherit auto-update settings from the pack, and the default enables them, so a pack installed years ago under default configuration can pull in resurrected code on its next update cycle.
Execution is unrestricted. Extensions across VS Code and compatible IDEs run with Node.js host access covering file operations, child processes, and outbound network calls. Bloom Security notes that an extension is not sandboxed in any meaningful sense where code execution is concerned. Installing a malicious one is remote code execution on the developer’s machine.
The victim pool is almost exclusively software developers, who hold source repository access, cloud credentials, deployment pipelines, and internal tooling. From the aggregate half-million downloads, and assuming very conservatively that half had auto-update enabled, the research projects a quarter of a million compromised developer endpoints inside 24 hours.
Divergent Vendor Handling
The two marketplaces responded on very different timelines, which is instructive for anyone assessing platform risk.
Eclipse Foundation received the report on February 5, 2026, and assigned all at-risk namespaces to the open-vsx account within hours, closing the registration path. It committed to blocking creation of packs referencing non-existent bundled extensions and extensions declaring non-existent dependencies. Both checks are implemented and enforced. Triage also revealed that Open VSX extension dependencies were subject to the identical vulnerability.
Microsoft received the report on February 17, 2026, with a full proof of concept and video demonstration. MSRC’s opening assessment placed it at Moderate severity and cited existing publisher resurrection prevention. Bloom Security pushed back with the video evidence and additional evidence of re-registering removed publishers, and Microsoft reopened the case. Engineering then confirmed a partial October release, with prevention active for admin actions since October and for user actions only as of that month. The staged rollout spanned October 2025 to June 2026 and is documented at github.com/microsoft/vsmarketplace/discussions/1708. Microsoft acknowledged that completion followed the report and added the researcher to its public security researcher acknowledgement page, without any data regarding why or any mention of the issue.
For operators, Bloom Security’s guidance reduces to two controls: validate that all bundled extensions and declared dependencies exist at pack submission, and protect namespaces referenced in existing published packs from open registration. Phantom pointers in a package index, the company argues, are not a data quality problem. They are attack surface. Open VSX addressed both points decisively and stands as the model.
Bloom Security has also published a detection script for identifying affected packs on individual endpoints, alongside tables of impacted bundles from both marketplaces.