VS Code Marketplace Flaw Lets Attackers Republish Names of Deleted Extensions

Summary of the finding

Security researchers at ReversingLabs reported a weakness in the Visual Studio Code (VS Code) Marketplace that permitted actors to reuse the names of extensions that had previously been removed. The discovery followed the identification of a malicious extension named “ahbanC.shiba” that ReversingLabs said behaved similarly to two other extensions, “ahban.shiba” and “ahban.cychelloworld”.

ReversingLabs said it made the discovery after it identified a malicious extension named “ahbanC.shiba” that functioned similarly to two other extensions – ahban.shiba and ahban.cychelloworld –

The core issue described by the researchers is a marketplace loophole allowing name reuse after deletion, creating an opportunity for attackers to republish extensions under the same or confusingly similar names to those previously available.

Why this matters: supply chain risk and developer trust

Code editors like VS Code are central to modern development workflows. Extensions augment IDEs with linters, language servers, debuggers and utilities that run with varying privileges and can access source code, credentials and local systems. That access makes extensions an attractive target for attackers seeking to introduce malware, exfiltrate secrets, or create persistence in developer environments.

When marketplaces allow reusing previously registered names, users who rely on name recognition and past experience can be misled into installing a malicious re-release. The effect is twofold:

• Users may trust an extension’s name as a proxy for authenticity and skip verification steps that would reveal a changed publisher or malicious code.
• Organizations that allow automatic or bulk extension installs based on name may inadvertently pull newly published, malicious packages into developer machines or CI environments.

In short, a name-reuse weakness increases the attack surface of the software supply chain by enabling impersonation and typosquatting-style deception inside an IDE marketplace.

Attack scenarios and practitioner analysis

Based on the description of the issue and standard adversary techniques, practitioners should consider the following plausible attack vectors and implications:

• Impersonation via name reuse: An attacker republishes a previously removed extension under the same or nearly identical name. Less observant users may not notice a different publisher identity and install the malicious version.
• Social engineering and update confusion: Users who remember a benign extension may accept an installation prompt or an “update” to a republished package without verifying the publisher or code changes.
• Privilege misuse: Extensions commonly request permissions or access to the file system and language server APIs. A malicious extension can abuse these to read source files, inject code into running tools, harvest credentials stored in the workspace, or propagate to other systems.
• Supply chain propagation: In teams where extensions are standardized through shared settings or provisioning scripts, a republished malicious extension can be distributed quickly across multiple developer machines and CI runners.

Operational teams should assume that visually similar names and historic familiarity are insufficient indicators of authenticity. Verifying publisher identity, examining the extension manifest and code, and monitoring for anomalous behavior are necessary controls.

Comparable incidents and ecosystem context

Marketplaces and package registries across ecosystems (npm, PyPI, container registries, and extension stores) have faced similar problems for years: typosquatting, name squatting, and republishing of packages to trick users. Malicious or insecure packages published to those registries have been repeatedly used to deliver malware, credential stealers and backdoors.

In the context of IDE extensions, prior incidents have shown that extensions can be an effective vector for supply chain attacks because they execute code in development environments and can be granted broad privileges. The VS Code Marketplace has become a focal point for developers and thus a logical target for actors seeking to compromise development workflows.

Actionable recommendations

The following mitigation measures are aimed at marketplace operators, enterprise security teams, and individual developers. They are practical steps to reduce risk from name-reuse attacks and similar supply chain threats.

• For marketplace operators (e.g., Microsoft / marketplace maintainers)
  • Implement name reservation: prevent previously used extension identifiers from being immediately reusable by a different publisher, or require explicit transfer authorization by the original publisher.
  • Enforce strong publisher identity verification: tie extension listings to verified accounts with multi-factor authentication and organizational verification for publishers representing brands.
  • Warn users on republished names: prominently display notices when an extension with a previously used name reappears under a different publisher or after deletion.
  • Introduce publisher continuity metadata: show lineage information such as “original publisher” and history of removals or transfers to help users assess authenticity.
  • Automate malware and behavioral scanning: perform static and dynamic analysis on submitted extensions, and flag suspicious changes from prior versions.
• For enterprise security teams and IT administrators
  • Adopt allowlists and managed extension policies: restrict which extensions can be installed in developer environments and enforce policies centrally where possible.
  • Block automatic installations and require manual review for new or republished extensions, especially those requesting elevated permissions.
  • Use endpoint and development environment monitoring to detect unusual extension behavior such as unexpected network connections, file exfiltration, or child process spawning.
  • Incorporate extension vetting into onboarding and CI/CD pipelines: include static analysis or sandboxed execution of extensions before permitting them in shared toolchains.
• For individual developers and extension users
  • Verify publisher identity: check the publisher name, publisher profile, and contact information before installing an extension; favor extensions with verifiable publisher credentials.
  • Inspect installation prompts: pay attention to requested permissions and reject extensions that ask for access beyond their stated purpose.
  • Prefer extensions with open source code and an active, auditable history. When in doubt, review the extension’s repository and changelog.
  • Run new or updated extensions in isolated environments where feasible, and scan extension packages with local security tools prior to installation.

Conclusion

The ReversingLabs report highlights a marketplace governance gap that can be exploited to republish deleted or similar-named extensions and deceive users. Because extensions run inside developers’ tools and can access sensitive artifacts, marketplace name reuse elevates supply chain risk and undermines trust.

Mitigations require coordinated action: marketplace operators should harden submission and naming policies, enterprises must enforce managed extension controls and monitoring, and developers should validate publisher identity and permissions. Together these steps reduce the likelihood that republished extensions become a foothold for broader compromise.

Source: thehackernews.com