Loophole allows threat actors to claim VS Code extension names

After discovering a malicious VS Code extension in June, ReversingLabs researchers noticed something odd: the name of the VS Code extension was identical to that of a malicious VS Code extension discovered in March. That shouldn’t be possible, according to VS Code Marketplace’s official documentation. Further investigation led to the discovery of a loophole on the VS Code platform that allowed for the reuse of legitimate, but discontinued VS Code extension names by malicious actors. 

This blog post will review what we found and what developers can do to protect themselves.

Introduction

Historically, VS Code Marketplace hasn’t been popular amongst malicious actors. A small number of malicious extensions were being published, and the malicious payloads found inside them were mostly taken from npm packages. Today, however, most malicious extensions RL finds on the Marketplace have been written specifically for VS Code Marketplace. 

One of the recent campaigns RL discovered in March contained simple malware in the VS Code extensions ahban.shiba and ahban.cychelloworld that were downloading and running second stage malware. The interesting part was the second stage itself: It was a ransomware in development, encrypting files in a test folder. These extensions were reported and removed from VS Code Marketplace, but RL continued monitoring for packages with this same capability.

In June, a new malicious extension called ahbanC.shiba was discovered. Compared with the earlier, ahban extensions, nothing changed except for the spelling of the extension’s unique ID. In fact, ahbanC.shiba presented the same capability as the previous two extensions, with malware downloading basic ransomware. 

However, what struck RL threat researchers wasn’t the capabilities of this new malicious extension, but its name: “shiba.”  That's an extension that is identical to one of the two malicious extensions discovered in March.

Why does that matter? Well, according to the official VS Code Marketplace documentation, that shouldn’t be possible. The VS Code documentation states that the name of each VS Code extension must be unique to the platform.

Following this discovery, RL's threat researchers looked into whether or not it was possible to reuse the name of a VS Code extension on the platform, despite the claims of official documentation.

The answer? "Yes." Here's how the RL threat research team’s investigation into this VS Code Marketplace anomaly exposed a loophole in the platform's handling of package names that could be abused by threat actors. 

How ransomware is delivered

In matching its predecessors, ahbanC.shiba was a simple downloader. The extension registered only one command: shiba.aowoo. Once the extension was added to VS Code IDE and this single command was called, a second malicious payload would be downloaded and run from hxxp[:]//54[.]85[.]145[.]93/payload[.]ps1 or hxxp[:]//54[.]85[.]145[.]93/payload_linux[.]ps1, depending on the operating system. 

The second stage was the same as we had previously seen in the extensions discovered this past March. The script would encrypt files in test folder C:\Users\$env:USERNAME\Desktop\testShiba and as a ransom, demand one Shiba Inu token – an Ethereum-based cryptocurrency – to be paid to a Shiba Inu wallet. Interestingly, like the extension’s two predecessors, no crypto wallet was added to indicate where exactly to send the demanded funds.

Figure 1: ahbanC.shiba’s second stage.

Understanding how extension identification works

To investigate why this extension was able to bypass VS Code Marketplace’s official documentation, it's important to understand how extension identification works. When working with- and publishing VS Code extensions, there is extensive documentation available on official websites where anyone can find examples and helpful tutorials on how to choose a name for the extension; set a display name; and publish the extension. All VS Code extensions come with the manifest file called package.json, where various information like name, display name and publisher can be defined. 

One of the important parts of each VS Code extension is something called a "unique ID," which is used to identify extensions. Here, the extension name and publisher are combined in the format <publisher>.<name> to create a unique ID. For example, the unique ID for our malicious extension is ahbanC.shiba, where the extension name is "shiba" and the publisher is "ahbanC."

Looking at its predecessor, you can see they have the same extension names, but different publishers.

Figure 2: Same name, different publishers.

According to the rules laid out in VS Code's official documentation, names should all be lowercase with no spaces. They also must be unique to the platform. As you can see here, however, that is not the case.

To prove that this loophole existed, we conducted a little experiment:

We started by creating a very simple extension with the imaginative name myextensiontest and the unique ID testrl777.myextensiontest. The extension was nothing special, and was basically just copied from VS Code Marketplace’s official tutorial. Then, RL tried to publish another extension with the same name — first using the same publisher, then switching to a new publisher: testrl778. In both cases, publishing failed, which is what we expected, since the new extension had the same name as the one available on VS Code Marketplace.

Figure 3: Unable to publish extension with the same name.

So how did extensions ahban.shiba and ahbanC.shiba end up having the same name despite the official documentation’s publishing rules?

VS Code Marketplace offers two options while managing extensions: Remove the extension, or unpublish it. Both options result in extensions not being available on VS Code Marketplace anymore, but they do differ.

When an author un-publishes an extension, its statistics are not removed from VS Code Marketplace. That means the owner can republish it anytime they prefer, but other VS Code developers are prevented from using that extension.

However, when an author removes an extension, both the extension and its statistics are completely removed from the VS Code Marketplace.

Our experiment revealed an important difference between these two options that RL proved with this experiment: While users still can’t reuse the name of the unpublished extensions, names of the extensions that are removed can be reused freely.

After unpublishing the extension, we tried to publish a “new” extension with the same name using both authors, testrl777 and testrl778. In both cases, publishing was unsuccessful, since the extension still existed on VS Code Marketplace even though it wasn’t available for download.

Figure 4a: Unpublished extension is not available.

Figure 4b: Not being able to publish extension with the same name.

However, once the old extension was removed from the platform, publishing new packages using the myextensiontest extension was able to occur, no matter which publisher RL choose to publish with our extension.

This means that the name of any extension that is removed from the Marketplace is in danger of being reused. That could potentially allow a threat actor to publish a malicious extension that claims the same name as a previous, legitimate VS Code extension that has since been removed.

RL researchers made additional experiments to further confirm this loophole, including trying to publish simple extensions using names of previously found malicious extensions. For example, we tried to publish the extension by the name Solidity-Ethereum, one of the names of a previously discovered malicious extension. Publishing was successful.

Figure 5a: Content of the extension testrl777.Solidity-Ethereum.

Figure 5b: Successful publishing using name of previously malicious extensions

This surprised the RL research team, but VS Code is not unique. We have seen the same technique used successfully with other open source platforms.

To cite one example: in early 2023, we discovered that the names of deleted packages on PyPI can also be reused. That inquiry happened after the discovery of a malicious package on PyPI named termcolour, a three-stage downloader published in multiple versions that re-used the name of a previous PyPI package, which had been removed from the public repository years earlier. When we carried out a similar experiment with PyPI packages, we were able to re-publish a Python package with a name identical to a previously published package using a different PyPI account.

However, according to the Common questions section found on the PyPI website, PyPI package names can be made unavailable if they were first used by malicious packages.

Even though VS Code Marketplace employs several measures to protect from malicious extensions, searching through its documentation and common questions yields no answers as to whether the names of malicious extensions can be reused.

The malware's timeline

After this experiment, RL researchers understood why the publishing of the Shiba Inu wallet extensions looked irregular.

The first two packages in this campaign, ahban.cychelloworld and ahban.shiba, were published initially in October of last year, and their latest versions were published in early March 2025. RL believes they were completely removed from the platform only a few weeks after the name was reused. A new extension, ahbanC.shiba, with the same extension name, shiba, but a different publisher, ahbanC, was published on March 24. New versions of the ahbanC.shiba extension appeared in early June. RL researchers first thought it was removed from the platform shortly after the newest version appeared. However, it turns out that it was instead unpublished at some point in June, because it wasn’t available on VS Code Marketplace, but its statistics could be retrieved with the vsce tool. 

By looking at available statistics, it was probably unpublished on June 17.

Figure 6: ahbanC.shiba statistics.

At the time of writing this, the extension is no longer available on VS Code Marketplace. But since it was only unpublished, a threat actor could re-publish it at any time in the future.

Figure 7: Timeline of publishing ahban.shiba and ahbanC.shiba.

RL researchers have already observed the names of extensions being reused. As seen in Figure 8, malicious extensions in a campaign uncovered last year had different publishers, but the same names. 

In this specific campaign, malicious extensions were targeting the crypto community with downloaders serving malicious second stages.

Figure 8: Table showing extensions having different publishers but same name.

There were also previous cases in which malicious extensions had the same display names as the original extensions that they were impersonating. 

The timing of ransomware being published on public repositories is noteworthy. Earlier this year, internal chat logs belonging to Black Basta, a ransomware-as-a-service offshoot of the notorious Conti gang, were leaked, as reported by Risky Business and later by Socket. Among other things, the conversations found inside the leakd chat logs indicated that members of Black Basta were planning to test public repositories for ransomware delivery. 

While this campaign on VS Code is most likely not connected to Black Basta activities, it shows that cybercriminal groups in general could potentially be looking at gaining ransom funds via public platforms like VS Code Marketplace.

Conclusion

The VS Code Marketplace is becoming increasingly popular amongst malicious actors. Just like with the targeting of PyPI, they are developing new ways to trick developers and users to download malicious packages instead of legitimate ones. 

The technique of reusing names of previously removed packages is something RL researchers have seen across several different repositories.

This time, the malicious actor reused their own malicious extensions. However, the discovery of this loophole exposes a new threat: that the name of any removed extension can be reused, and by anyone. That means that if some legitimate and very popular extension is removed, its name is up for grabs. 

To help developers and development organizations check if the packages they include in their development are malicious or not, they can rely on RL’s Spectra Assure Community. 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.

Figure 9: Extension ahbanC.shiba on Spectra Assure Community

The Spectra Assure Community helps in preventing supply chain attacks by providing package transparency. This newly discovered campaign, in addition to our latest research on VS Code Marketplace in which a malicious pull request infected a legitimate extension, are great examples of how the platform spots such risks.

The lesson to be learned from this campaign is that it’s important to remember that many dangers are lurking on VS Code Marketplace and other open-source repositories. It is essential for developers and users of these platforms to be mindful and aware of what is being included in the development cycle.

Indicators of Compromise (IOCs)

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of RL investigation of this malicious software supply chain campaign.

Second-stage payload