Open VSX has recently made headlines by removing three extension identifiers from its list of malicious extensions. This development comes in response to the legitimate projects they impersonated regaining access to their names. The unblocking of these identifiers—specifically AlDuncanson.react-hooks-snippets, magne-sjaastad.opm-flow-editor-support, and rumbledb.jsoniq-vscode—marks a significant step in restoring publishing capabilities for the affected project maintainers. However, it also underscores critical vulnerabilities in the current supply-chain tracking system, revealing that a single extension ID can be repurposed for both malicious artifacts and later legitimate releases.
Between August 16 and August 20, Open VSX executed the unblocking for these three identifiers, which were part of a larger malicious campaign targeting the extension name registry. These identifiers were among a total of 77 names that were compromised during what has been termed an "evil-twin" campaign. This nefarious initiative involved the cloning of legitimate Visual Studio Code (VS Code) Marketplace extensions and the publication of these fakes under unauthorized accounts on Open VSX.
The original campaign was chronicled by Manifold Security and spanned from July 26 to August 1. It specifically targeted extension names that existed within Microsoft’s VS Code Marketplace but had not yet been claimed by their true maintainers on the Open VSX platform. The attackers exploited this gap, publishing counterfeit versions—usually designated as version 0.0.1—that not only used unrelated accounts but also cloned descriptions from the original projects. Notably, all 77 of these counterfeit samples communicated with the same recently registered infrastructure managed through mangorbit[.]com.
In addition to simple impersonation, nineteen of the malicious extensions delivered an expanded reconnaissance payload. This involved collecting not just host and editor metadata, but also accessing Git configuration and repository details. Such information included remote repository hosts, organization names, commit-email domains, branches, commit hashes, workspace paths, and CI/CD identifiers. The implications of such data breaches could be severe, particularly in build runners or cloud development environments where this information could expose sensitive repository paths like GITHUB_REPOSITORY or CI_PROJECT_PATH.
According to reporting from Socket, two of the projects affected—the OPM Flow Editor Support and RumbleDB JSONiq/XQuery—have since published legitimate updates. However, React Hooks Snippets reclaimed its namespace without an official Open VSX release at that time. This situation raises immediate concerns about the efficacy of Open VSX’s ID-only blocklisting approach. When the legitimate owner reclaims an ID, retaining the block could prevent the legitimate extension from being published; conversely, removing it not only allows the legitimate version to be published but also erases any record of the malicious history associated with that identifier.
As evidenced by the three names that were restored, the malicious versions primarily utilized low-version releases such as 0.0.1, while the legitimate updates recently published under these identifiers show a progression in versioning practices. For example, legitimate releases now include versions published on August 21 and August 23.
The deeper issue here transcends mere repository management; it touches on the broader problem of namesquatting in software ecosystems. Socket engineer John Tuckner documented 491 Open VSX IDs over the past year that corresponded to VS Code Marketplace projects. Alarmingly, 415 of these impersonated extensions rank among the top 10,000 most popular in Microsoft’s marketplace, illustrating the significant namespace gaps across different extension systems.
In response to these vulnerabilities, Open VSX has introduced improvements aimed at enhancing forensic visibility. Its recent 1.1.x release has implemented immutable extension versions, preventing publishers from modifying already published versions. Additionally, a newly introduced preview Registry Changes Feed logs essential events such as publication, deactivation, and removal. While this append-only feed can assist security teams in tracking the lifecycle of extensions, the lack of public guidelines concerning how to manage identifiers that have been reclaimed post-abuse remains a notable gap.
For defenders in this space, this incident acts as a stark reminder that an extension name alone should not be taken as an indicator of trustworthiness. Organizations are advised to maintain detailed records that include not only the extension ID but also the exact version, VSIX hash, publisher identity, source repository, installation source, and first-seen date. Historical detections must be specifically tied to the malicious extension rather than being broadly applied to an identifier that may be reclaimed by its legitimate owner in the future.
Furthermore, extension maintainers are urged to proactively claim their Open VSX namespaces to protect them from potential abusive tactics, even if the registry is not yet widely used as a primary distribution channel. For enterprise teams, best practices should include validating publisher ownership and package provenance in their configuration files to prevent reliance on extension names alone as indicators of security.
In summary, the recent unblocking of identifiers by Open VSX illustrates both a significant step toward restoring legitimacy but also highlights a systemic vulnerability within extension management.