ReversingLabs has identified an integrity gap in the Visual Studio Code Marketplace: when an extension is hard-deleted, its name can be re-registered by a different publisher. The finding surfaced during an investigation of a malicious extension, ahbanC.shiba, which mirrors earlier variants ahban.shiba and ahban.cychelloworld observed in March 2025.
ReversingLabs: malicious loaders masquerading as VS Code extensions
The three extensions operated as loaders, retrieving a PowerShell payload from a remote server. That payload encrypted files within a testShiba folder on the victim’s desktop and demanded payment in Shiba Inu tokens. While indicators point to early-stage malware development, the behavior already demonstrates practical risk for developers who trust VS Code’s extension ecosystem.
Extension identity in VS Code and how name reuse undermines trust
VS Code extensions are uniquely identified by a pair <publisher>.<name>, with the name constrained to lower case, no spaces, and expected to be unique marketplace-wide. ReversingLabs observed cases where only the publisher differed while the extension name was reused, raising questions about identity issuance and protection.
Analysis showed that after a hard delete, an original extension name becomes available for new publishers to claim. This does not occur with a standard unpublish, where the artifact remains but is delisted. The hard-delete behavior creates a path for brandjacking—the hijacking of a recognizable extension name to distribute new, potentially malicious content.
Parallels with PyPI and lessons from other ecosystems
Python’s Package Index (PyPI) has faced similar issues. Under PEP 541, PyPI can reserve or block names linked to abuse, deterring re-registration by unrelated parties. ReversingLabs notes the VS Code Marketplace lacks an equivalent safeguard to prevent reuse of names tied to malicious activity. The broader supply chain community has repeatedly seen the impact of identity and ownership gaps—e.g., npm’s event-stream takeover (2018) and the left-pad removal (2016)—which illustrate how namespace control directly affects integrity and availability.
Threat scenarios: name-squatting, typosquatting, and silent replacement
Name reuse raises the likelihood of name-squatting (claiming a legitimate name after deletion), typosquatting (using a lookalike name), and stealthy replacement during search or scripted installs. If a popular extension disappears due to moderation, legal, or operational reasons, adversaries can quickly register the same name, ride prior reputation, and ship loaders, ransomware, or spyware.
How a VS Code brandjacking attack unfolds
A developer sees a familiar extension name in the Marketplace and installs it, overlooking that the publisher has changed or that the publication date is recent. Post-install, the extension can request elevated permissions, execute commands via the terminal, and pull a payload over the network. In the observed case, the payload encrypted files in a desktop folder and demanded crypto-based payment, modeling a supply chain compromise via the IDE.
Mitigations for platform owners, organizations, and developers
For the VS Code Marketplace and platform owners: reserve (quarantine) names after deletion; block names previously tied to abuse; strengthen publisher verification and enforce multi-factor authentication; display explicit warnings on re-registering previously deleted names; provide a transparent ownership history; require signed VSIX artifacts and clear capability declarations that surface risky behaviors at install time.
For organizations: adopt an allowlist of verified publishers and extensions; pin dependencies to publisher IDs and specific versions; mirror or proxy the Marketplace via a vetted internal catalog; continuously monitor extension installations and IDE network activity; enforce EDR/AV controls and PowerShell restrictions where feasible to detect or block loader behaviors.
For developers and maintainers: prefer unpublishing over hard deletion to preserve name integrity; use verified publisher accounts with strong authentication; publicize extension fingerprints (name, publisher, version, and hash); sign releases and consider SBOMs for transparency; communicate promptly with users about distribution changes to reduce the chance of impostors filling the gap.
The ahbanC.shiba incident underscores how identity management gaps—in this case, post-deletion name reuse—expand the software supply chain attack surface. Closing the loop with name reservation, stronger publisher verification, transparent ownership histories, and disciplined dependency management will make brandjacking of VS Code extensions far less practical and help prevent malicious loaders from entering trusted developer workflows.
