Fake Open VSX Extensions Hijack AMD, Azure, Salesforce and Government Namespaces

Fake Open VSX extensions have hijacked high‑trust namespaces like AMD, Azure, Salesforce, Hyperledger, and a U.S. government agency on the Open VSX Registry, silently harvesting Git and CI metadata from developer and CI environments while posing as legitimate tools.

Each package cloned the name, namespace, and description of a real, unrelated extension and re‑published it under a low version number, usually 0.0.1, from a pseudonymous account that did not own the namespace and was not the original author.

In effect, these were “evil twins” of real extensions: indistinguishable by name and description, but wired to attacker‑controlled infrastructure.

As of August 3, 2026, Open VSX Extensions has removed the malicious listings. That takedown does not revoke deployed code: any image, workspace configuration, or devcontainer pinned to one of these names will continue to load the extension locally, and the beacon will continue to fire on every editor start.

The 77 samples form a spectrum rather than two clean families, but they cluster into lightweight beacons and full reconnaissance payloads.

Fifty‑eight are small, roughly 1.6–3.3 KB. They send the machine hostname and, in some cases, the workspace folder name or editor version, plus a per‑package tracking identifier.

Delivery varies POST requests to /api/v1/metrics or /api/v1/events, GET query strings, or multi‑endpoint failover logic but the collected data is narrow.

These variants are enough to fingerprint machines and tie them to specific counterfeit packages, without touching source code.

Nineteen carry a substantially larger payload, around 10 KB, and run comprehensive environment profiling a few seconds after activation.

A single request bundles hostname and OS username, editor name and version, host kind and machine ID, platform and architecture, locale and timezone, and both the folder name and full filesystem path of the open workspace.

It then walks .git: origin and upstream remotes reduced to host and organisation, the domain portion of the commit email, the current branch and HEAD commit SHA, and up to sixty installed extension IDs.

Between July 26 and August 1, 2026, Manifold Security identified 77 counterfeit Open VSX extensions beaconing to the same newly registered domain, mangorbit[.]com.

From CI, it collects marker names and the values of GITHUB_REPOSITORY, CI_PROJECT_PATH, Azure DevOps collection URI, Buildkite organisation slug, CircleCI project username, Codespace name and Gitpod context URL, yielding the full private repository path for projects running in CI or cloud development environments.

The extension also reads the editor’s telemetry opt‑out setting and sends data regardless.

The reconnaissance variants document most of this behaviour openly under a “Telemetry” section in their Open VSX listings.

Hostname, username, workspace path, Git organisation and email domain, branch and commit are all disclosed, along with assurances: no source code, credentials, tokens, SSH materials, browser data, arbitrary environment variables, or filesystem modifications. Manifold’s review confirms those limits hold in code.

The single material misstatement concerns CI. The listings claim CI values never leave the machine, describing them as mere indicators of which CI platform is present.

In reality, the extensions send both the marker names and the CI environment values, including the private repository identifiers that are the most sensitive field in the payload.

The listings also omit three behaviours: reporting whether repository configuration files pulled the extension in; reading and transmitting the editor telemetry preference; and querying a DNS TXT record (_beacon.) to discover replacement endpoints if the hardcoded ones fail dynamically.

Crucially, the extensions do nothing else. Apart from a checkmark in the status bar and a trivial “active” message command, their sole function is the beacon.

The word “telemetry” stands in for any legitimate feature, and the documentation becomes the mechanism of consent for behaviour that would otherwise look anomalous.

The lightweight majority spans almost every stack and skill level Amiga debugging, LEGO EV3 MicroPython, Minecraft JSON schemas, Vim cheatsheets, WordPress, Perl, CoffeeLint, Hugo suggesting wholesale harvesting of extension names rather than precise targeting.

The nineteen reconnaissance payloads skew toward organisational environments where Git and CI identity are materially valuable: blockchain tooling for IOTA, Move and Obyte; enterprise platforms such as Salesforce Marketing Cloud, ApexSQL and ConfigCat; an aerospace and automotive bus protocol (UAVCAN DSDL); and a U.S. federal agency namespace.

Fake Open VSX Extensions

Across the full set, hijacked namespaces include AMD, Artsy, LEGO Education, Hyperledger, Azure, IOTA, Salesforce OSS, a .gov agency (“ssagov”), and marketplace.visualstudio, impersonating the marketplace itself.

While nineteen samples are not enough to define a strategy, they concentrate the richer payloads in environments where mapping private repositories and CI projects carries the greatest operational value.

All 77 extensions communicate with mangorbit[.]com, registered on July 15, 2026 eleven days before the publishing wave via a registrar that redacts registrant details.

The apex serves a generic landing page; collector subdomains such as pulse.mangorbit[.]com, pulse2.mangorbit[.]com, api.mangorbit[.]com and randomized cb.mangorbit[.]com subdomains respond “ok,” confirming live servers acknowledging input rather than parked DNS entries.

The recon payload’s retry logic is explicitly built for interference. Requests fire roughly at fifteen minutes, fifty minutes and three‑and‑a‑half hours after activation, then every seven to eight hours, resuming on every editor restart and stopping only after seven days.

Any offline, firewalled or proxy‑blocked machine will be retried for a week. Endpoint lists are redundant, and any HTTP response even an error code is treated as success, emphasizing arrival over payload.

If all endpoints fail, the extension queries the _beacon TXT record to retrieve a new base URL, allowing the operator to relocate collection infrastructure post‑takedown without shipping an updated extension and without tripping most egress filters.

One field is particularly telling: a flag indicating whether the open workspace’s devcontainer.json or .vscode/extensions.json explicitly referenced the extension’s ID.

That distinction config‑driven installs versus human choice is exactly what an operator would need to understand how their packages are being pulled into fleets.

This campaign sits in a broader pattern of attacks exploiting the trust gap between Microsoft’s VS Code Marketplace and the Eclipse‑run Open VSX Registry.

Socket’s June “GlassWASM” report documented trojanized Open VSX clones of legitimate VS Code Marketplace extensions, reproducing publisher IDs, names, versions, descriptions and upstream GitHub links while adding ChaCha20‑obfuscated WebAssembly payloads.

In July, researchers publicly called out a namespace‑hijacking flaw in Open VSX that lets attackers claim any Microsoft Marketplace publisher namespace that is unregistered on Open VSX and push arbitrary code under it, with auto‑update enabled by default in many AI‑augmented IDEs.

Manifold’s earlier analysis of a counterfeit “Markdown All in One” extension on Microsoft’s own Marketplace showed the same pattern from the other side: borrowed extension metadata, clear‑text beacons of username and hostname to a hardcoded IP, and silent remote file retrieval.

Anthropic’s July 30 disclosure and OpenAI’s Hugging Face incident underline the automation risk: Anthropic reported that during an evaluation, one of its models published a malicious PyPI package under a name that existed only in a fictional setup document, yet fifteen real systems downloaded and executed it within an hour.

Why use the 2026 Agentic SOC Buyer’s Guide? 8 Best Platforms Compared – Download the 2026 Buyer’s Guide