VS Code Marketplace Abused by Threat Actors to Deliver Malware via Trusted Extensions

A recently uncovered vulnerability in the Visual Studio Code (VS Code) Marketplace has allowed malicious actors to hijack discontinued extension names and slip malware past unsuspecting developers.

In June, ReversingLabs (RL) researchers discovered a new malicious extension, ahbanC.shiba, that bore the same “shiba” identifier as a ransomware-capable extension removed in March—despite official documentation asserting extension names must be unique.

This anomaly exposed a loophole that permits reusing names of removed extensions, opening the door to supply-chain attacks targeting developers’ IDEs.

Historically, most VS Code threats repackaged malicious npm packages. However, RL’s threat intelligence shows a shift: today’s malicious extensions are being crafted specifically for VS Code, with custom downloaders and second-stage payloads.

In March, RL identified two extensions—ahban.shiba and ahban.cychelloworld—that downloaded and executed a nascent ransomware module, encrypting files in a test folder and demanding payment in Shiba Inu cryptocurrency.

These extensions were promptly removed from the Marketplace.

In June, RL researchers spotted ahbanC.shiba, which functioned identically to its predecessors except for the publisher’s name (ahbanC vs. ahban).

The extension registered a single command (shiba.aowoo) that, when invoked, downloaded a PowerShell script from a remote server to encrypt files on the victim’s Desktop test folder.

Despite sharing the “shiba” identifier, the extension should have been blocked by VS Code Marketplace’s uniqueness checks—until RL dug deeper.

After unpublishing the extension, we tried to publish a “new” extension with the same name using both authors, testrl777 and testrl778.

How the Name-Reuse Loophole Works

VS Code extensions declare a unique ID composed of . in their package.json manifest.

Official guidance states that extension names must be lowercase, space-free, and unique platform-wide.

In practice, RL researchers found that the Marketplace enforces uniqueness only for unpublished extensions: publishers cannot reuse names of extensions that were merely un-published (statistics remain), but names of removed extensions (statistics erased) become fair game.

To confirm this, RL created a test extension, testrl777.myextensiontest, and observed that publishing a second extension with the same name failed when the original remained unpublished, regardless of publisher.

However, once the original extension was removed, RL successfully published new extensions named myextensiontest under different publishers.

The same experiment with the malicious “Solidity-Ethereum” name confirmed that threat actors could freely claim names of previously removed malicious packages.

Broader Implications and Timeline

This loophole mirrors similar vulnerabilities on other open-source platforms. In 2023, RL reported that deleted PyPI package names could also be repurposed, enabling malicious actors to publish trojanized Python packages under legitimate-looking names.

The ungated, open-source platform provides free security and risk assessments for public repositories such as npm, PyPI, RubyGems and NuGet. Recently, RL introduced the addition of VS Code Marketplace to the platform.

Unlike PyPI, however, VS Code Marketplace provides no mechanism to permanently reserve or blacklist names once removed.

RL’s timeline indicates that the original ahban.shiba extensions were published in October 2024 and removed by March 2025.

The new ahbanC.shiba appeared on March 24, 2025, with updated versions in June 2025, before being unpublished around June 17. Because it was unpublished rather than removed, its name remains reserved—yet any removed extension’s identifier is vulnerable.

With VS Code Marketplace growing in popularity, developers must remain vigilant. RL recommends:

1. Monitor Extension Origins: Verify publishers and review extension histories before installation.
2. Enable Code Signing and Reviews: Favor extensions with maintained code signing and community audits.
3. Leverage Security Tools: Use platforms like RL’s Spectra Assure Community, which now supports VS Code Marketplace, to scan and assess repository risk.

The name-reuse loophole highlights a critical supply-chain risk: any removed extension—legitimate or malicious—can be resurrected by new actors seeking to distribute malware under a trusted name.

As open-source repositories continue to be weaponized, defense must extend beyond code to include identifier management policies and proactive monitoring of extension ecosystems.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.