Extension Confusion Lets Attackers Hijack Trusted Names Across VS Code Registries

A coordinated campaign used 77 counterfeit VS Code extensions to collect developer and CI environment data through Open VSX.

The packages copied trusted extension names, namespaces, and descriptions, but were published from unrelated pseudonymous accounts.

Between July 26 and August 1, 2026, all 77 extensions contacted the same newly registered domain, mangorbit[.]com.

Most used version 0.0.1 and replaced the legitimate extension’s extension.js with a beaconing component. Open VSX removed the extensions by August 3, but the collection infrastructure remains online.

The campaign included two broad payload types. Fifty-eight lightweight extensions, sized between 1.6 KB and 3.3 KB, sent the hostname and sometimes the workspace folder name or VS Code version. They also included a unique tracking identifier.

VS Code Namespace Hijacking

The other 19 packages were more invasive. Their roughly 10 KB payloads activated within seconds of editor startup and collected the hostname, OS username, VS Code version, machine ID, platform, architecture, locale, timezone, and workspace filesystem path.

They also inspected Git metadata. The code extracted remote Git host and organisation details, the domain portion of the configured commit email, the active branch, and the latest commit SHA.

It additionally enumerated installed extensions and checked proxy details. Most significantly, the reconnaissance payloads read CI environment values.

These included GitHub repository names, GitLab project paths, Azure DevOps collection URIs, Buildkite organisation slugs, CircleCI project names, Codespaces names, and Gitpod workspace URLs.

On a build runner, this information can expose a private repository’s full path. The extension listings labelled this activity as “Telemetry.”

They correctly stated that the packages did not take source code, credentials, tokens, SSH keys, browser data, or arbitrary environment variables.

However, they falsely claimed that CI values never left the local machine. The code transmitted those values.

The packages also recorded whether the workspace’s devcontainer.json or .vscode/extensions.json caused the installation.

This can help an operator identify extensions automatically installed by repository configuration rather than manually selected by a developer.

None of the extensions delivered the feature they claimed to provide. Their visible functionality was limited to a status-bar checkmark and a message stating that the extension was active.

The real purpose was beaconing data to remote infrastructure. The campaign exploits a gap between Microsoft’s VS Code

Marketplace and Open VSX. Both registries host legitimate extensions, but they use separate namespace ownership and publisher-verification systems.

A trusted name on one registry may be unclaimed on the other, manifold said. This creates an extension-confusion risk.

Automated tools, devcontainer configurations, provisioning scripts, and AI agents can install an extension by name without evaluating publisher history, download counts, verification status, or source-repository lineage.

Detect, investigate, and respond faster with in-browser data inspection from ANY.RUN. Gain complete phishing visibility to strengthen your SOC and reduce MTTR