Summary
- Researchers linked 77 counterfeit Open VSX extensions through common code and collection infrastructure.
- Nineteen packages collected detailed Git, workspace, machine, and CI metadata, including private repository identifiers.
- The packages have been removed, but installed copies and workspace configurations are not automatically cleared.
The Open VSX Registry has removed 77 counterfeit extensions that copied the identities of legitimate developer tools while transmitting information about the machines, repositories, and continuous-integration environments on which they ran.
Manifold Security detected the extensions between 26 July and 1 August. All 77 reused the name, namespace, and description of an unrelated genuine extension, usually appeared under a low version number such as 0.0.1, and communicated with infrastructure under the same newly registered domain.
The packages were removed from Open VSX by 3 August, but removal from the registry does not uninstall copies already present on developer workstations, build runners, development containers, or machine images.
Manifold divided the samples into two broad groups. Fifty-eight transmitted limited information, commonly a machine hostname and, in some cases, the workspace folder name or editor version. The remaining 19 collected a substantially wider set of reconnaissance data.
Those extensions gathered the local username and hostname, machine identifier, operating system, editor version, platform architecture, locale, timezone, and the full path of the open workspace. They also inspected selected Git configuration files to identify remote hosts and organisations, the domain used for commit email addresses, the current branch, and the latest commit reference.
In continuous-integration and cloud-development environments, the packages collected values associated with GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces, and Gitpod. That could disclose the full name or path of a private repository even though the code did not read the project’s source files.
The researchers found no collection of passwords, authentication tokens, SSH material, browser data, or arbitrary source code. The extensions’ listings described much of the activity as telemetry, but the disclosure was incomplete. It said continuous-integration values would remain on the machine, while the code transmitted them.
None of the counterfeit packages delivered the functionality claimed in its listing. Most displayed a status indicator or activation message before sending data to the operator’s server. Manifold did not attribute the campaign and declined to conclude whether the operator intended espionage, target selection, experimentation, or another purpose.
All samples communicated with subdomains of mangorbit.com, which had been registered on 15 July, 11 days before the first extensions appeared. Some variants were designed to retry transmission for up to seven days, use several collection endpoints, and request a replacement address through a Domain Name System text record if their original infrastructure stopped responding.
The campaign exploits a trust problem created by separate extension registries. A publisher may control a name in Microsoft’s Visual Studio Marketplace without holding the equivalent namespace on Open VSX. A counterfeit package can therefore occupy a name that appears legitimate to a user, development environment, automated provisioning process, or AI agent.
The distinction becomes more important as extension installation moves away from direct human review. Development containers, workspace configuration files, image-building scripts, and coding agents can request a package by name without examining its publication history, ownership, verification status, download count, or relationship to the genuine project.
In that environment, registry identity becomes part of the software supply chain. A package need not contain an exploit or heavily obfuscated malware to create exposure. An extension runs inside a developer tool with visibility into project structures, local paths, version-control context, and build-system variables that can reveal commercially sensitive work.
The legitimate publishers whose names were copied were not involved, and their genuine extensions were not modified. The incident instead relied on impersonation, namespace differences, and installation decisions made with insufficient provenance information.
Open VSX’s removal of the listings prevents new installations from the public registry, but existing development environments may retain the code. Manifold has published package identifiers and hashes for investigation. The operator’s identity, the number of installations, and the eventual use of the collected information remain unknown.
