By NHI Mgmt Group Editorial TeamBased on Manifold Security: “77 "Evil Twin" Open VSX Extensions: 19 Copy Private Repo and CI Data to a New Domain” (August 4, 2026)

TL;DR: 77 counterfeit Open VSX extensions copied real VS Code Marketplace names and namespaces, and 19 of them collected git and CI identity such as repository paths, branch data, and project identifiers, according to Manifold Security research. Name-based installation now creates a trust gap because automated tools can resolve the wrong package before any human review occurs.

At a glance

What this is: Manifold Security found 77 counterfeit Open VSX extensions that impersonated real VS Code Marketplace packages, with 19 of them collecting detailed git and CI identity from developer environments.

Why it matters: This matters because package-name trust is no longer enough for editor extensions, devcontainer workflows, and agent-driven installs that can silently pull malicious code into private repositories and build systems.

Context

The immediate problem is extension-name trust in a multi-registry ecosystem where the same package name can exist in more than one place with different ownership. When install decisions are automated by developers, devcontainers, or agents, namespace similarity becomes a supply-chain control issue rather than a simple user-interface problem.

This case also exposes an identity boundary that many teams still underprotect: the editor environment often has access to git remotes, branch metadata, repository paths, and CI context. That makes a misleading extension listing more than an installation nuisance, because it can become a path from tooling trust to repository and pipeline reconnaissance.

Key questions

Technical breakdown

How extension squatting turns package names into a trust boundary

Open VSX and the VS Code Marketplace do not share a single trust namespace, so a package name can be legitimate in one place and malicious in another. That creates a resolution problem when installations happen by name rather than by verified publisher lineage. The attack is not only about user confusion. It is about software that resolves names automatically and cannot infer which registry, publisher, or provenance policy should apply. In that model, a squatted extension can look syntactically correct while being operationally hostile.

Practical implication: Treat package resolution as an identity decision and require publisher, registry, and version controls before automated extension installation.

What the reconnaissance payload learns from a developer workstation

The more capable samples do not just beacon a hostname. They collect workspace path, git remotes, branch and commit data, CI markers, and environment-specific project identifiers such as repository names and workspace context URLs. That combination is enough to identify a private codebase, not just a machine. On build runners and cloud development environments, these fields can reveal the exact repository and pipeline context even when credentials are stripped. The problem is data minimisation failure inside a tool that was presented as ordinary telemetry. See the Data Exfiltration Guide.

Practical implication: Review editor and workspace permissions as sensitive data flows, not as harmless productivity settings.

Why automated tooling makes lookalike extensions harder to detect

Human review used to be the last line of defence, but that assumption weakens when agents, devcontainer configs, and provisioning scripts install extensions without checking provenance context. A name requested by an automated workflow can be accepted as if it were the intended package, even when it came from a different registry or an unverified publisher. That is why this pattern is closer to resolution abuse than to a classic phishing event. The control failure is not merely that someone clicked the wrong listing. It is that the system delegated trust to a name alone.

Practical implication: Move extension approval upstream into allowlists, registry restrictions, and provenance checks for non-interactive installs.

Threat narrative

Attacker objective: The attacker wants to identify valuable repositories, environments, and CI contexts that can support follow-on compromise or targeted supply-chain abuse.

  1. Entry occurred when automated extension installation resolved a squatted Open VSX name that matched a real VS Code Marketplace extension.
  2. Credential access was not the goal, but the recon payload harvested repository and CI identity data that can expose private project structure and operational context.
  3. Impact is achieved when the hostile extension runs inside developer or build environments and exfiltrates sensitive repository metadata without any functional warning to the user.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Extension squatting is now an identity governance problem, not just a marketplace hygiene issue. When an editor extension can impersonate a real project name and be installed by automation, the real control boundary is publisher identity and registry provenance. That shifts the question from whether a user noticed the listing to whether the environment can prove what it was allowed to install. Practitioners should treat extension namespaces as governed trust assets, not as convenience labels.

The named concept here is repository identity leakage through tool trust. The payload does not need credentials to be damaging if it can map a workspace to a private repository, branch, commit, and CI context. That is enough to turn a developer tool into an intelligence source for later intrusion or targeted phishing. In practice, this means the metadata emitted by everyday tooling must be classified as sensitive operational identity data.

Automated install paths collapse the human review model that extension marketplaces quietly depend on. Devcontainers, agent workflows, and provisioning scripts can accept the wrong package at machine speed, which makes publisher verification and registry pinning more important than install-count heuristics. The governance failure is not the existence of a bad package; it is the assumption that a person will always validate what the system has already accepted. Security teams should harden the decision point before installation, not after execution.

This campaign shows that minimised payloads can still be highly useful to attackers. Even when credentials are stripped and the code avoids overt malware behaviours, repository hostnames, branch names, and CI identifiers can expose enough structure to plan a more focused follow-on attack. That is a classic example of security teams underestimating low-noise telemetry as harmless. The right lens is not whether data is obviously sensitive in isolation, but whether it reveals an environment’s trust relationships.

Read next: Data Exfiltration Guide

What this signals

Package-name trust is becoming a weak control in environments where software installs software. Devcontainers, CI bootstrap steps, and agent workflows reduce the chance that a person will notice a mismatched publisher before execution. The control point has to move from end-user recognition to policy-based provenance enforcement at install time.

Repository identity leakage is the more important consequence than simple telemetry collection. A package that learns the branch, remote host, workspace path, and CI project context can help an attacker map where the most valuable code lives and which pipeline to target next. That makes developer-tool metadata part of the attack surface, not background noise.

Teams should expect the same pattern to appear wherever names are resolved automatically. Any ecosystem that allows broad package naming, multiple registries, and weak publisher verification can be abused by lookalike distribution. The durable defence is to make identity, provenance, and approval state part of the software resolution decision, not an afterthought.

For practitioners

  • Tighten extension allowlisting for automated installs Require explicit approval for editor extensions installed by devcontainers, images, or agent workflows, and restrict those workflows to verified publishers and approved registries.
  • Audit developer and build images for squatted package names Search .vscode/extensions.json, .devcontainer/devcontainer.json, and image build logic for extension IDs that resolve to Open VSX or other alternate registries without publisher verification.
  • Treat workspace metadata as sensitive Classify git remote URLs, branch names, repository paths, and CI project identifiers as sensitive telemetry when they appear in editor or extension data flows.
  • Block recent-domain callbacks from editor processes Alert on outbound requests from editor extensions to newly registered domains shortly after startup, including DNS TXT lookups used as dynamic endpoint discovery.

Key takeaways

  • Counterfeit extensions can weaponise ordinary package resolution when automation trusts names more than publishers.
  • The most consequential data here is not source code or credentials but repository and CI identity metadata.
  • Provenance controls, registry pinning, and runtime monitoring all matter, but they have to be enforced before installation begins.

Related NHI Mgmt Group resources: Web Application Attacks Guide · Code Signing Security Guide · Data Exfiltration Guide · Command and Control (C2) Guide

Key terms

  • Combo Squatting: Combo squatting is a typosquatting variant where an attacker adds a plausible word to a legitimate package or project name to look authentic. In software supply chains, the goal is to blend into normal developer workflows and reduce suspicion long enough for malicious code to be installed and executed.
  • Repository Identity: An identity that can read, write, trigger, or authenticate through a code repository or its connected automation. It may be human, bot, token, or service account. The key governance issue is not where it lives, but whether its permissions are owned, reviewed, and revoked on time.
  • Publisher Verification: Publisher verification is the process of confirming that a piece of content came from the entity that claims to have published it. In practice, it relies on signed attestations and independent checks rather than visual branding or the hosting platform alone.
  • Automated Package Resolution: Automated package resolution is the machine-driven selection and installation of software based on names, versions, or configuration files rather than manual review. It becomes risky when the resolver cannot distinguish a trusted package from an impersonator in a second registry or marketplace.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to govern identity trust, privilege, and lifecycle decisions across modern environments.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org