Skip to main content
Emerging ThreatsMalware & Ransomware

Fake Open VSX Extensions Harvest Private Data from Impersonated Developer Tools

Cluttered developer's workstation with laptop, code editor, and scattered papers.

77 counterfeit Visual Studio Code extensions appeared on the Open VSX registry between July 26 and August 1, each republishing the name and namespace of a genuine extension account it did not belong to, and most of them beaconed to a single domain registered 11 days before the first fake package surfaced.

How the counterfeit extensions were named and distributed

Research published by Manifold Security on August 4 found 77 listings that impersonated real developer tools by republishing the name and namespace of an extension while not being owned by the original account. Squatted namespaces across the set included AMD, LEGO Education, Hyperledger, Azure, Artsy, Salesforce OSS, a U.S. federal agency and marketplace.visualstudio, which impersonated the marketplace itself. All of the packages contacted the same collector domain; that domain had been registered 11 days before the first fake package appeared.

Open VSX removed the packages on August 3, though Manifold reported the operator infrastructure remained live at the time of their write-up.

What the 19 full collectors took: git and CI identity

While most fake extensions sent little more than a hostname, Manifold identified 19 packages that carried a far fuller data-collection payload. Seconds after activation those extensions sent the host name, operating system user name, editor details and machine ID. They then read the repository open in the editor and collected the git remote host and organization, the commit email domain, the branch and the HEAD commit.

They also collected continuous integration identifiers, including the GitHub repository name, GitLab project path and Codespace name. Manifold emphasized the operational impact: “On a build runner or a cloud development environment, that is the full private repository name, not just the organization.” In other words, on automated or cloud environments the data could expose exact private repository identifiers rather than only high-level organization names.

Disclosure text versus the code’s behavior

Each malicious listing included a "Telemetry" disclosure enumerating most of the fields the code actually transmitted and contained assurances that no source code, credentials or tokens were taken. Manifold examined the code and found those stated limits largely accurate.

There was a notable exception: one listing asserted that continuous-integration data covered marker names only and never values, but the code sent both names and values. Manifold noted that this single mismatch meant the most sensitive field in the payload was the one the listing claimed not to transmit. Functionally the extensions offered no legitimate features beyond a status-bar checkmark and a single command that displayed a message box; their observable purpose was to beacon telemetry.

Persistence, resilience and operator controls built into the collector

The collector domain was registered through a registrar that redacts registrant details and on a three-year term. The code treated any HTTP response as success — including error responses — and was designed to retry across seven days and to resume on every editor restart. If every endpoint failed, the beacon would query a DNS TXT record for a replacement collector address, enabling the operator to relocate infrastructure without issuing updated packages.

The payload also reported whether the workspace’s devcontainer or extensions configuration had pulled the extension in, letting the operator distinguish installs caused by repository provisioning from installs a person chose manually. Manifold argued that distinction matters because name resolution and automated provisioning increasingly install by package name across registries whose ownership rules can make a squatted name indistinguishable from the genuine package.

What this means for technologists, procurement teams, and end users

  • Technologists and security teams: Manifold recommended pinning by publisher and version where registries are mirrored internally, treating the unverified-publisher banner as a blocking condition in automated installs, and alerting on editor processes contacting recently registered domains shortly after startup.
  • Procurement and mirror maintainers: Because automated provisioning can pull by name, Manifold’s findings underscore the need to verify publisher identity when mirroring external registries and to prefer pinned, verified artifacts rather than blind name resolution.
  • End users and developers: The fake extensions demonstrated that an apparently innocuous install — a checkmark in the status bar or a single command — can be a vehicle for extracting repository and CI identifiers, particularly in cloud development environments and CI runners where repository identifiers translate directly into private resource names.

The incident closes with a pointed operational fact: Open VSX removed the listings, but the collector infrastructure remained live at the time of the disclosure, and the code was explicitly engineered to survive takedowns by shifting endpoints via DNS. Manifold’s specific mitigations offer immediate, concrete steps for defenders; the remaining open question is whether registry governance and publisher verification will change in response to packages that weaponize trust in names and namespaces.

Original story