VS Code Marketplace Flaw Lets Attackers Reuse Deleted Extension Names, Researchers Warn

Summary of the discovery

Security researchers at ReversingLabs identified a loophole in the Visual Studio Code Marketplace that can be abused to republish extensions using the same names as previously removed packages. ReversingLabs reported the finding after it observed a malicious extension called “ahbanC.shiba” that behaved similarly to two earlier extensions — ahban.shiba and ahban.cychelloworld — suggesting the actor reused a familiar name to evade scrutiny or ride existing trust signals.

Background and why this matters

IDE extensions are a core part of modern developer workflows: they add linters, debuggers, language servers, and other productivity tools that run with the developer’s privileges and frequently access source code and credentials. Because extensions integrate deeply with development environments, a malicious or compromised extension can have outsized access to sensitive code, secrets, build systems and deployment pipelines.

Reusing the name of a removed extension is an undermining of a basic trust mechanism that many users rely on. Users often make installation decisions based on a familiar name or prior positive experience; when that name can be re-registered by a different publisher — potentially a malicious actor — that trust becomes a liability. The same basic dynamic has been exploited in package ecosystems and browser extension stores through typosquatting, impersonation, or by re-publishing similarly named packages.

Technical implications and threat analysis

At a technical level, the vulnerability reported by ReversingLabs centers on identity and namespace control in the Marketplace. If a removed or deleted extension name can be claimed again without clear provenance or strong publisher verification, attackers gain a cheap vector for impersonation. The likely attacker goals include:

• Leveraging name recognition to increase installs and distribution of malicious code.
• Delivering payloads that exfiltrate secrets, execute arbitrary code in developer environments, or alter build artifacts.
• Persisting as a seemingly legitimate tool in multiple developer workstations where users trust the extension’s name.

For defenders, the core challenge is the violated trust assumption: that an extension’s name, particularly if previously seen, correlates to a benign or known publisher. Once that assumption is broken, conventional heuristics such as searching by name or relying on community familiarity become less reliable.

Comparable cases and industry context

The reuse or impersonation of package and extension names is a recognizable pattern in software supply chain abuse. In various ecosystems — package managers, browser extension stores and other plugin marketplaces — attackers have used similar tactics: typosquatting, registering look-alike names, or re-publishing previously removed packages under new ownership. These patterns are well-documented in industry reporting and are a common component of supply chain threat models for development environments.

While the specific mechanics vary across marketplaces, the underlying lesson is consistent: marketplace identity controls and publisher verification are critical to reduce impersonation and frictionless re-publication that benefits malicious actors.

Actionable recommendations for practitioners

Security teams and developers should assume that marketplace metadata alone (name, display icon, or prior familiarity) is insufficient to establish trust. The following mitigations reduce exposure and improve detection:

• Establish an extension inventory and control policy. Enumerate which extensions are permitted on developer machines and enforce that list via endpoint management or extension management controls where possible.
• Vet publishers, not just package names. Before installing an extension, verify the publisher identity (organization, publisher URL, official repository) and cross-check code repositories or official project pages rather than relying on Marketplace listing alone.
• Prefer offline or internally vetted installs for critical tools. For sensitive environments, distribute vetted VSIX packages through internal artifact repositories or software distribution mechanisms rather than allowing open Marketplace installs.
• Scan extension code and package artifacts. Use static analysis and malware scanning for extensions — particularly for newly installed or recently updated packages — to detect obfuscated code, network I/O, or suspicious behaviors before they run in developer contexts.
• Restrict extension privileges and follow least privilege. Where configurable, limit workspace and file access for extensions, and review permission prompts. Assume that an extension with broad access may be capable of exfiltration or code modification.
• Monitor for anomalous behavior. Instrument developer endpoints and CI systems for signs of unusual network connections, unexpected processes launched by the editor, or modification of build artifacts following extension installs or updates.
• Pin versions and maintain reproducible environments. Lock extension versions in shared development environment configurations where practical, and audit changes to those locks before approving updates.

Operational guidance for security teams and vendors

Beyond immediate mitigations, organizations and marketplace operators should pursue systemic controls to limit the effectiveness of name reuse attacks:

• Enforce stronger publisher verification and provenance. Marketplaces should require verifiable publisher accounts and display clear provenance indicators (e.g., verified organization badges or linked code repositories) so users can distinguish original maintainers from new claimants of an old name.
• Implement namespace protections. Consider retention policies that prevent re-registration of recently deleted names or that require additional verification when a name is claimed by a different publisher.
• Improve transparency around publisher changes. When packages are removed and later re-published under different ownership, marketplaces should make that history visible to users — including prior owner metadata, removal reasons where appropriate, and a clear indication that the publisher has changed.
• Support artifact signing and integrity verification. Encourage or require cryptographic signing of extension packages and provide tooling for clients to enforce signature checks against trusted signers.
• Provide enterprise controls. Offer administrative controls for organizations to manage permitted publishers and extensions and integrate those controls with existing endpoint management and policy enforcement frameworks.

Practical detection and incident response steps

If you suspect a malicious extension has been installed or a name-reuse abuse is in play, take the following steps:

• Isolate affected hosts and collect forensic artifacts: extension package files, logs showing network or file-system access by the editor, and timestamps of installs or updates.
• Revoke or rotate any secrets that may have been exposed. Prioritize credentials used on developer workstations, CI tokens, and any keys that could impact production systems.
• Scan repositories and build systems for signs of tampering or unexpected commits. Because extensions run with developer privileges, attackers can attempt to modify source or build scripts.
• Notify stakeholders and the marketplace operator. Provide indicators (package name, publisher, hashes) so the marketplace can investigate and take corrective measures such as removing the malicious listing and blocking the publisher if necessary.

Conclusion

The ReversingLabs finding underscores a persistent class of risk: when marketplaces fail to enforce clear provenance and publisher controls, attackers can exploit name reuse to masquerade as trusted tools. For developers and security teams, marketplace metadata should never be the sole basis for trust. Combining publisher verification, controlled distribution, artifact scanning and operational monitoring reduces exposure and makes it harder for attackers to weaponize familiar names to distribute malicious extensions.

Source: thehackernews.com