Infosecurity

Squatted Open VSX Extensions Slip Past the Registry and Drain CI Data

Published

on

Malicious Packages Hit the Open VSX Registry

Counterfeit extensions that copied the names of legitimate developer tools were discovered on the Open VSX registry. Roughly a quarter of them were quietly harvesting the git and continuous integration identity of anyone who ran them.

Security firm Manifold Security published its findings on August 4. The team flagged 77 packages that appeared between July 26 and August 1. Each one republished the name and namespace of a real extension from an account that had zero ownership rights to it.

Every single package beaconed to one domain. That domain was registered just 11 days before the first malicious package surfaced.

What the Payload Actually Collected

Most of the packages were light on data. They sent little more than a hostname. But the squatted namespaces tell a story of their own. The list included AMD, LEGO Education, Hyperledger, Azure, Artsy, Salesforce OSS, a US federal agency, and marketplace.visualstudio — a name that impersonated the marketplace itself.

The other 19 packages carried a much heavier payload. Seconds after activation, they sent the hostname, the operating system username, editor details, and the machine ID. Then things got more serious.

The malicious code read the repository currently open in the editor. It pulled the git remote host and organization, the commit email domain, the branch, and the HEAD commit. It also grabbed continuous integration values, including the GitHub repository name, GitLab project path, and Codespace name.

“On a build runner or a cloud development environment, that is the full private repository name, not just the organization,” Manifold explained.

The Disclosure Was the Disguise

Here’s the twist. The listings actually disclosed what they were doing.

Each one carried a “Telemetry” section that enumerated most of those fields accurately. The disclosure also included assurances that no source code, credentials, or tokens were taken. Manifold checked those claims against the code and found they held up.

Almost all of them, anyway.

One listing stated that continuous integration data covered marker names only and never values. The code, however, sent both. The single most sensitive field in the payload was the one the disclosure explicitly said was not being sent.

These extensions had no other real function. A status bar item rendered a checkmark. One command displayed a message box. Then the beacon fired.

Built to Outlive the Takedown

The collector domain was registered through a registrar that redacts registrant details. The registration term was three years. The code treated any HTTP response as success — including an error — and retried across seven days, resuming on every editor restart.

If every endpoint failed, the beacon queried a DNS TXT record for a replacement collector address. That let the operator relocate infrastructure without shipping new packages.

The payload also reported whether the workspace’s own devcontainer or extensions configuration had pulled the extension in. That distinction matters: it separates installs a repository caused from installs a human chose.

Manifold argued this is critical because name resolution is increasingly automated. Agents and provisioning scripts install by name across two registries whose separate ownership rules make a squatted name indistinguishable from the real one.

How to Protect Yourself

Open VSX removed the packages on August 3, though the infrastructure remained live at the time of writing. If you’re worried about similar attacks, Manifold offered some practical advice:

  • Pin by publisher and version where registries are mirrored internally
  • Treat the unverified-publisher banner as a blocking condition in automated installs
  • Alert on editor processes contacting recently registered domains shortly after startup

This isn’t the first time extension name abuse has caused problems. Earlier research highlighted how malicious VS Code extensions exploit a name reuse loophole. The pattern keeps repeating because the registries haven’t closed the gap.

The takeaway is simple. If you’re running automated installs across a team, don’t trust names alone. Verify the publisher. Check the version. And treat any telemetry disclosure in a random extension as a red flag, not a comfort.

Leave a Reply

Your email address will not be published. Required fields are marked *

Trending

Exit mobile version