The discovery of 77 counterfeit extensions on the Open VSX marketplace demonstrates how attackers can exploit developer trust without immediately deploying conventional malware or stealing credentials. The extensions impersonated legitimate development tools and secretly transmitted information about the computers, workspaces, repositories and continuous integration environments on which they were installed. 

The campaign used an “evil twin” technique in which counterfeit extensions copied the names, namespaces and descriptions of genuine Open VSX packages but were published through unrelated accounts. Developers searching for familiar tools could therefore install the imitation after seeing branding and functionality descriptions that closely resembled the legitimate extension.

Most of the counterfeit packages used the low version number 0.0.1 and did not provide the functionality advertised in their listings. Instead, they displayed a status message suggesting that the extension was active and then transmitted information to attacker-controlled infrastructure.

The affected listings impersonated tools associated with a wide range of technologies and organizations, including AMD, Microsoft Azure, Salesforce, Hyperledger, LEGO Education and IOTA. At least one extension also used a namespace associated with a United States government agency.

The campaign shows that extension impersonation is not limited to copying popular themes or formatting tools. Attackers may imitate enterprise, blockchain, cloud and government-related development products to reach users working within specific technical communities.

The extensions were linked through shared infrastructure

Researchers connected all 77 extensions to the same campaign because they used common code, displayed similar network behaviour and transmitted information to infrastructure under the `mangorbit[.]com` domain.

The domain had been registered only shortly before the first counterfeit packages appeared. Different extensions communicated with subdomains such as `pulse`, `pulse2`, `api` and randomly generated addresses under another subdomain.

Each extension also contained its own tracking identifier. This allowed the operator to determine which counterfeit package had been installed and potentially compare the types of developers and organizations attracted by different impersonated tools.

Such tracking can help an attacker understand which brands and technologies produce the most valuable installations. An extension pretending to support Azure may attract cloud developers, while one impersonating a Hyperledger tool may identify users working with blockchain infrastructure.

Even when no password or source code is stolen immediately, the installation itself becomes a signal about the victim’s interests, technology stack and potential organizational role.

The majority collected basic system information

Fifty-eight of the extensions primarily transmitted the hostname of the affected computer. Some variants also collected the name of the workspace folder and the version of the code editor.

This may appear to be limited information, but hostnames and workspace names can still reveal valuable context. Enterprise device names frequently include employee names, department codes, office locations, project identifiers or organizational naming conventions.

A workspace folder may expose the name of an internal product, customer, repository or development initiative. Even a simple directory named after an unreleased application or confidential customer project can provide intelligence that was never intended to leave the organization.

The code editor and version can also help attackers understand the development environment and identify whether the user is running an outdated or potentially vulnerable product.

Basic reconnaissance is often valuable because it allows an operator to decide which systems deserve further attention. Attackers do not always begin by stealing everything available. They may first identify valuable targets and reserve more aggressive activity for a later stage.

Nineteen extensions performed extensive reconnaissance

The remaining 19 extensions collected a substantially broader profile of the developer and the surrounding environment.

The information included the operating-system username and hostname, machine identifier, editor name and version, processor architecture, locale and timezone. The packages also transmitted the full filesystem path and name of the workspace open inside the editor.

This information can help identify the user, device and probable geographic location. A username may correspond with an employee’s identity, while a timezone and locale can reveal the region in which the developer works.

The complete workspace path may expose company names, internal project structures and storage conventions. For example, a path containing a customer name, confidential product code or internal department can reveal considerably more than an ordinary anonymous usage statistic.

Machine identifiers also allow the operator to recognise the same system across repeated transmissions, even when network addresses change.

Together, these details create a persistent profile of the affected developer and provide a foundation for future targeting.

Git metadata can expose private projects

The reconnaissance extensions inspected selected files within the workspace’s `.git` directory.

They collected information about Git remote hosts and organizations, the domain used in the developer’s configured email address, the current branch and the HEAD commit hash.

The packages reportedly did not steal source-code contents, but Git metadata can still expose sensitive information. Remote addresses may reveal private GitHub, GitLab, Bitbucket or self-hosted repository infrastructure.

Organization and repository names can identify internal products, customers or research projects. Branch names may reveal upcoming releases, security fixes, mergers, experiments or confidential features.

A branch named after an unreleased product or security vulnerability can provide intelligence even when the attacker never sees the files stored within that branch.

The HEAD commit hash can also help an operator identify the exact project state being used by the victim. When combined with publicly accessible repositories, the hash may allow the attacker to correlate the local workspace with a particular source-code version.

The configured email domain can reveal the developer’s employer or customer relationship. This can help attackers distinguish personal installations from enterprise development environments.

CI/CD and cloud-development information was also collected

The extensions searched for information associated with several continuous integration and cloud-development platforms, including GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces and Gitpod.

They also enumerated up to 60 extensions installed in the developer’s editor.

This information can reveal how an organization builds and releases its software. The presence of particular CI/CD identifiers may indicate which platforms the company uses, while installed extensions can disclose programming languages, cloud providers, database technologies, infrastructure tools and AI coding assistants.

A developer with Kubernetes, Terraform, Azure and database extensions installed presents a different target profile from someone using only frontend web-development tools.

The collected information could help an attacker design highly relevant phishing messages or malicious extensions for the same organization. A future campaign could impersonate a tool already present in the environment or claim to resolve a problem associated with the victim’s actual CI platform.

CI metadata can also disclose private repository names, pipeline identifiers and development paths. Although these values may not provide direct access, they improve the attacker’s understanding of the software-delivery process.

Reconnaissance can be the first stage of a larger attack

Researchers did not find evidence that the 77 extensions stole passwords, source code, authentication tokens, SSH keys or browser data.

That limitation is important and should not be exaggerated. The activity observed was primarily profiling and reconnaissance rather than confirmed credential theft or full system compromise.

However, collecting detailed development information without a clear legitimate purpose remains a serious security concern.

The operator could use the data to identify high-value developers, organizations and repositories before launching a more targeted campaign. It could also support future package impersonation, phishing or supply-chain attacks.

An attacker who knows that a particular organization uses GitLab, CircleCI and Azure can create much more credible messages and tooling than an attacker working from a generic recipient list.

The collected inventory of installed extensions could also identify opportunities for creating additional evil twins. If many victims use a particular tool that is not yet available on Open VSX, the operator could publish a convincing imitation and target the same population again.

Reconnaissance reduces uncertainty for the attacker. It reveals which systems are worth attacking, which technologies should be impersonated and which social-engineering themes are likely to succeed.

Disclosure of “anonymous metrics” was incomplete

The extension listings reportedly disclosed that they collected what was described as anonymous usage information. They also claimed not to access source code or credentials, which was consistent with the technical findings.

However, the packages collected substantially more information than an ordinary developer would reasonably understand from a general statement about usage metrics.

Machine identifiers, usernames, complete workspace paths, Git organizations, repository metadata, email domains and CI/CD indicators can become identifying when combined.

Information does not remain anonymous merely because the extension avoids requesting the user’s full name. A unique machine identifier linked with a corporate email domain, private repository path and workspace name can provide a detailed identity profile.

Telemetry should be limited to the minimum information required for a clearly stated product purpose. Developers should also be given meaningful control over whether it is collected.

In this case, the extensions did not provide their advertised functionality, making the claimed telemetry purpose even less credible. Collecting usage statistics for a tool that does not actually perform the described function is rather ambitious product analytics.

Persistence and fallback infrastructure increased resilience

Some variants continued attempting to transmit collected information for as long as seven days.

The extensions supported multiple collection endpoints and could query a DNS TXT record to discover replacement infrastructure if the original hardcoded servers became unavailable.

Using DNS as a fallback channel provides the operator with flexibility. If defenders block or remove one endpoint, the attacker can publish a new destination through the DNS record without updating every installed extension.

This technique also demonstrates planning beyond a temporary research experiment. The operator designed the collection system to survive infrastructure disruption and retry transmission over an extended period.

Security teams should therefore block the complete `mangorbit[.]com` domain rather than only the specific subdomains initially observed.

DNS logs should be reviewed for queries to the domain, including randomized subdomains, because those records may reveal which systems attempted to communicate with the campaign infrastructure.

Open VSX removal does not uninstall local copies

Open VSX removed the extensions from the marketplace, but deletion from the registry does not automatically remove them from code editors where they have already been installed.

Affected developers and organizations must identify and uninstall the counterfeit packages manually.

This distinction is important across every software marketplace. Removing a malicious application prevents new installations but does not neutralize copies already running on user devices.

Organizations should search endpoint inventories, editor configuration files and workspace recommendations for the extension identifiers published by researchers.

Workspace configuration deserves particular attention because projects can recommend or automatically install editor extensions. A malicious extension may therefore return when a developer reopens a project, rebuilds a development container or synchronizes editor settings to another device.

Security teams should also inspect user profiles, virtual development environments, containers and remote workspaces. Developers may use the same extension across local editors, GitHub Codespaces, Gitpod environments and cloud-hosted workstations.

Every environment in which an affected extension was active should be treated as having disclosed the corresponding system and repository metadata.

Editor extensions have extensive access

Visual Studio Code-compatible extensions execute with considerable access to the developer’s environment. Depending on the extension and editor configuration, they can read workspace files, execute processes, make network requests and interact with development tools.

An extension installed to provide syntax highlighting or a theme may therefore receive far more access than its visible function appears to require.

This creates an imbalance between user perception and technical authority. A developer may consider an extension a minor interface customization while the editor treats it as executable software operating within the development environment.

Organizations should evaluate editor extensions through the same software-risk process used for endpoint applications and build dependencies.

The publisher, source repository, required permissions, update history and network behaviour should all be considered before deployment.

Extensions should not be approved merely because they appear in a marketplace. A marketplace provides distribution and discovery, not an absolute guarantee that every package is safe.

Evil twin attacks exploit visual similarity

The counterfeit packages reused legitimate names, namespaces, descriptions and branding while being published from unrelated accounts.

Developers searching quickly may focus on the visible extension name and icon while overlooking the exact publisher identity and unique extension identifier.

Attackers exploit this by making the counterfeit appear sufficiently familiar to survive a brief review. Low download numbers may be ignored when the tool appears specialized or newly published.

Organizations should teach developers to verify the publisher and official source repository before installation.

The extension should ideally be linked from the legitimate project’s documentation rather than discovered solely through marketplace search.

Users should be cautious when several packages have nearly identical names or when an extension claims to represent a major company but is published through an unrelated personal account.

Marketplaces should also strengthen namespace protection for recognized organizations and government agencies. Allowing unrelated accounts to imitate trusted namespaces creates predictable opportunities for abuse.

Download counts and reviews should not be treated as decisive evidence because they can be manipulated or accumulated before a malicious update is introduced.

Developer systems are valuable intelligence targets

The campaign reinforces the strategic value of development environments to attackers.

Developers work with source repositories, cloud platforms, build pipelines, internal documentation and credentials that can provide pathways into wider enterprise systems.

Even when an extension collects only metadata, that metadata describes how software is built, where it is stored and which services the organization relies upon.

A corporate network scan reveals devices and services. A developer-environment scan reveals the organization’s future products, build architecture and trusted supply-chain relationships.

This information can support industrial espionage, targeted intrusion or preparation for a later software supply-chain compromise.

Organizations should therefore treat developer telemetry and repository metadata as sensitive operational information rather than harmless technical detail.

Project names, private repository hosts and CI/CD identifiers should not leave the environment without an approved and documented reason.

Network controls can reveal unexpected extension behaviour

Editor extensions commonly require internet access to retrieve documentation, language servers, updates and cloud functionality. Blocking all extension communication is therefore impractical for many development teams.

However, security teams can monitor which processes and extensions initiate outbound connections and whether those destinations match the extension’s stated purpose.

A local syntax-highlighting tool has little legitimate reason to transmit machine identifiers, workspace paths and Git repository information to a newly registered domain.

DNS filtering and secure web gateways can block known campaign infrastructure, while endpoint telemetry can identify which editor process initiated the communication.

Organizations should establish baselines for approved developer tools and alert when an extension contacts previously unseen infrastructure.

Newly registered domains, randomized subdomains and repeated retry activity should receive additional scrutiny.

Where technically possible, development environments should use controlled outbound access, internal package proxies and approved extension registries rather than unrestricted communication with arbitrary endpoints.

Extension allowlisting can reduce exposure

Enterprises can maintain an approved list of editor extensions required for development work.

The allowlist should identify the exact publisher, extension ID and permitted version range rather than relying only on display names.

New extensions should undergo review before being deployed broadly. Updates introducing unexpected telemetry, network connections or obfuscated code should also trigger renewed assessment.

Organizations should be cautious about automatically synchronizing extensions across personal and professional editor profiles. A developer installing a questionable extension on a personal device should not cause it to appear automatically within a managed work environment.

Workspace-level recommendations should be reviewed during code review because they can influence which extensions developers install when opening a project.

Development containers and cloud workspaces should use pre-approved extension lists rather than allowing every project to retrieve arbitrary marketplace packages.

These controls introduce some administrative effort, but that inconvenience is preferable to allowing every repository and marketplace listing to extend the trusted software base silently.

Incident response should assess the exposed intelligence

Because the observed extensions did not steal credentials or source-code contents, a full credential reset may not be automatically required solely because one was installed.

However, organizations should determine exactly which variant was present and what information it transmitted.

The affected machine should be checked for the extension ID, installation time, activation history and network communication with `mangorbit[.]com`.

Security teams should identify which workspaces were open while the extension was active and what repository and CI/CD metadata those projects contained.

This helps assess what the operator may now know about the organization.

The information could include private repository hosts, project paths, branch names, commit identifiers, corporate email domains, installed development tools and cloud-platform usage.

Those details should be considered when reviewing future phishing attempts and counterfeit packages. Teams may need to warn affected developers about attacks referencing real repository names or internal development platforms.

The extension should be removed from local, remote and cloud development environments, and the domain should be blocked throughout the organization.

Endpoint and DNS logs should also be searched retrospectively to identify additional developers who may have installed one of the counterfeit packages.

The broader cybersecurity lesson

The Open VSX campaign demonstrates that malicious extensions do not need to steal passwords or deploy ransomware immediately to create security risk.

Reconnaissance itself has value. By collecting device, workspace, Git and CI/CD metadata, the operator can map development environments and identify organizations, technologies and repositories worth targeting later.

The activity also shows how easily visual trust can be manipulated in extension marketplaces. A familiar name, copied description and plausible icon can persuade developers to install code from an unrelated publisher.

Organizations should therefore treat development extensions as executable supply-chain components. They require publisher verification, controlled deployment, behavioural monitoring and continuous review.

Developers should obtain extensions through official project documentation, verify unique publisher identities and question telemetry that does not match the tool’s function.

Security teams should maintain inventories of approved extensions, monitor outbound editor traffic and block infrastructure linked to known campaigns.

Most importantly, organizations should avoid dismissing metadata exposure because no credential file was stolen. Repository names, workspace paths, email domains and CI/CD identifiers can reveal how the organization develops software and where its most valuable assets may be located.

The 77 extensions effectively turned developer editors into reconnaissance sensors for an unknown operator.

Although the campaign stopped short of confirmed credential theft or source-code collection, it gathered enough context to support significantly more targeted attacks in the future.

Protecting development environments therefore requires more than securing source files and access tokens. It also requires protecting the operational information surrounding them.

An attacker who knows which tools, repositories, branches and pipelines an organization uses is already better prepared for the next stage. Defenders should make sure that stage is considerably less convenient than installing another counterfeit extension.

77 extensions on the Open VSX marketplace impersonated legitimate developer tools while transmitting information about the systems and development environments where they were installed. [...]

Source: 77 Open VSX extensions found harvesting developer info via Bleeping Computer — published 04 Aug 2026.