What Bloom Security's Extension Resurrection Research Means for Extension Pack Governance

Ask a security team to name the least governed system in the enterprise and few will say “the developer laptop.” They should. It changes daily. Extensions, packages, plugins, and AI tooling get assembled on the fly, rarely pass through review, and remain largely invisible to endpoint detection. Bloom Security‘s latest research turns that abstraction into a measurable exposure across roughly half a million downloads and more than 750 extension packs.

The vulnerability is called Extension Resurrection, and it affected both Open VSX and the Visual Studio Code Marketplace. What makes it worth a board-level conversation is not the exploit chain. It is the trust model the exploit chain borrows.

One Install Decision, Ten Unreviewed Consequences

When a developer installs an extension pack, they are not installing one tool. They are accepting a curated list of dependencies, every one of them granted deep access to the filesystem, running processes, and the network.

The pack was reviewed. Its contents were not. Bloom Security identifies that gap between what a user trusts and what actually gets installed as precisely where the attack lives.

Extension packs therefore behave as a risk multiplier. A single approval quietly expands the attack surface by five, ten, or more components that nobody explicitly evaluated. The research is unambiguous about the required posture change: treat extension packs within the same threat model as direct extension installs, and review the bundle manifest rather than the pack name.

Volume Is Working Against Defenders

Scale deserves attention here. In the first six months of 2026, the VS Code Marketplace nearly doubled in size. Between the two marketplaces, roughly 1,400 new extensions ship every single day. AI tooling has let teams move faster than before, and the output is an explosion of new software landing continuously.

Every developer runs at least one extension outside the defaults of their chosen IDE. That baseline was never the interesting part. The interesting part is that the catalog defenders would need to vet is growing faster than any manual review process can absorb.

What the Attack Actually Required

The technical prerequisites were modest, which is the point.

Both marketplaces permitted packs to reference extensions that did not exist. Bloom Security calls those dangling references Shadow Dependencies, and they arise either when a pack is mirrored to Open VSX without one of its bundled components, or when an extension referenced by a live pack is deleted.

Extensions are identified by publisher or namespace paired with an extension ID, so hijacking one means claiming the original publisher or namespace rather than just an available name. Both platforms allowed open registration of those names, including names that published software actively referenced.

Bloom Security’s scan quantified the field. Open VSX: 94 of 321 packs carried a shadow dependency with an unregistered namespace. VS Code Marketplace: 677 of 4,179 packs carried a shadow dependency, 60 of them under an unregistered publisher. Two of those were used for a live proof: prettify-json under mohsen1 on Open VSX, and control-snippets under svipas on the VS Code Marketplace.

Open VSX initially rejected an exact version match because it already held a ghost record from a mirrored manifest. Incrementing the version resolved that instantly, since packs reference bundled extensions by ID without pinning versions.

The Part That Should Worry Risk Owners

Installation was never the only vector. Auto-update configuration for bundled extensions is inherited from the pack, and the default is enabled. Anyone who installed an affected pack in the past, under default settings, could receive attacker-controlled code on a routine update.

Extensions run with Node.js host access. They read and write files, spawn child processes, and reach the network. Bloom Security’s assessment is that an extension is not sandboxed in any meaningful sense with respect to code execution, so a malicious install is functionally remote code execution on the machine.

That machine belongs to a software developer. Source repositories, cloud credentials, deployment pipelines, internal tooling. Applying a deliberately conservative estimate that half of the affected downloads had auto-update on, the research arrives at roughly a quarter of a million compromised developer endpoints within a day.

The Control Set Being Recommended

Bloom Security lists three capabilities security teams need, and none of them are novel. The difficulty is that most organizations lack all three for this surface.

The first is inventory of installed extensions and packs across the organization. The second is visibility into IDE configuration, specifically whether auto-update is enabled and for which extensions, plus whether policy limits installs to a pre-approved list. The third is extension scanning that audits capabilities, security posture, and risk for each installed extension, treated as a continuous process covering every new version rather than a one-time exercise.

For developers, the guidance is narrower. Auto-updated extension packs behave like auto-updates for every extension they bundle. Install once does not mean static forever. Periodically review what the IDE has actually installed, not just what was chosen.

Vendor Response as a Governance Signal

Bloom Security reported to the Eclipse Foundation on February 5, 2026, and to Microsoft via MSRC on February 17, 2026.

Eclipse assigned all at-risk namespaces to the open-vsx account within hours, then implemented a pre-publication check now blocking packs with non-existent bundled extensions and extensions with non-existent dependencies. Triage also surfaced that extension dependencies were vulnerable to the same technique. Bloom Security describes the experience as very positive and points to Open VSX as a model for marketplace response.

Microsoft’s path was longer. MSRC’s first assessment was Moderate severity on the basis that the Visual Studio Marketplace already had publisher resurrection prevention in place. Bloom Security disputed that with video evidence and additional examples of re-registering removed publishers, and the case was reopened. Engineering subsequently confirmed a partial fix from October and stated that prevention had covered admin actions since October and user actions only as of that month. The two stages landed in October 2025 and June 2026 respectively, documented at github.com/microsoft/vsmarketplace/discussions/1708. Microsoft acknowledged the completion arrived after the report. The eight-month interval between stages left real exposure for user-action resurrection, which Bloom Security demonstrated.

The broader lesson does not stop at extensions. The endpoint attack surface expands constantly through installs, updates, configuration drift, and AI tools pulling in fresh dependencies. Bloom Security’s argument is that everything running there needs to be continuously known, vetted, and governed as an ongoing process rather than a periodic audit. Organizations without that visibility, the research concludes, sit a few clicks away from an incident.