Secure Bulletin Navigating the cyber sea with knowledge
Home > Articolo > Fake VS Code Extensions Quietly Siphoned Git and CI Secrets From Developers
Fake VS Code Extensions Quietly Siphoned Git and CI Secrets From Developers
Read Time:3 Minute, 10 Second

A batch of 77 fake extensions uploaded to the Open VSX marketplace has shown just how easily an everyday developer tool can be turned into a covert data-collection channel. The packages copied the names, namespaces, and descriptions of real, trusted extensions almost exactly, then quietly reported back to the same newly registered domain. The campaign ran between July 26 and August 1, 2026, before the listings were finally pulled from the marketplace on August 3.

Copycats With a Payload

Researchers at Manifold traced the packages to accounts with no relationship whatsoever to the original extension authors. Each one reused a familiar identity, frequently published at a suspiciously low version number like 0.0.1, while the actual extension.js file underneath had been swapped out for code built to beacon information to the outside world. Some listings even labeled the behavior “telemetry” on their marketplace description, a framing that obscured what the code was truly doing.

Most of the fake packages, 58 of the 77, functioned as lightweight beacons, reporting little more than a hostname and occasionally a workspace folder name or editor version. The other 19, however, ran a far more invasive reconnaissance routine the moment they activated.

What the Reconnaissance Variants Actually Grabbed

Beyond basic device fingerprinting, the more aggressive extensions collected:

  • Operating system username, device identifiers, and full local file paths
  • Git metadata, including the host and organization pulled from origin and upstream remote URLs, the domain portion of the configured commit email, the active branch, and the latest commit hash
  • CI/CD environment variables from GitHub Actions, GitLab CI, Azure DevOps, Buildkite, CircleCI, Codespaces, and Gitpod, which on a build runner can expose the full name or internal path of a private repository
  • A list of other installed extensions

Perhaps most concerning, the code checked the editor’s telemetry preference but sent the collected data regardless of whether the user had opted out, directly contradicting the “stays on your machine” framing used on some of the listing pages.

Built to Stick Around

The collection infrastructure was engineered for resilience rather than a quick smash-and-grab. The packages used multiple hosts under the same parent domain, retried failed connections for up to seven days, and treated essentially any HTTP response as a successful delivery. If a hardcoded collection endpoint stopped responding, the malicious code could fall back to querying DNS TXT records to fetch a replacement address, making simple domain blocking only a partial defense.

Why This Matters Beyond a Single Marketplace

The bigger risk here isn’t the 77 packages themselves, most of which are now delisted, but the automated pipelines that installed them without a human ever reviewing the choice. Devcontainer configurations, editor provisioning scripts, and onboarding automation frequently install extensions by name alone, without verifying publisher identity, download history, or project lineage. That gap is exactly what this campaign exploited, and simply removing the listings from Open VSX does not undo installations already baked into workstation images, build servers, or repository configuration files.

What Development Teams Should Do Now

Security and platform teams should search developer and CI images for matching entries in files like .vscode/extensions.json, .devcontainer/devcontainer.json, and .devcontainer.json, then confirm exactly what got installed. From there, teams should block the identified campaign domain, pin internally mirrored extensions to a specific publisher and version rather than trusting name matches, and treat “unverified publisher” warnings as a hard stop for any automated installation process. It’s also worth adding detection rules for editor processes reaching out to newly registered domains shortly after startup, along with DNS TXT lookups using beacon-style subdomain labels. As development tooling keeps absorbing more automation, this incident is a reminder that editor extensions deserve the same scrutiny as any other third-party dependency running inside a company’s software supply chain.

Share: Twitter  |  Facebook  |  LinkedIn
Join the discussion

This is a blog in the Fediverse: you can find this article everywhere with @blog@securebulletin.com and every comment/answer will appear here.

If you want to comment on Fake VS Code Extensions Quietly Siphoned Git and CI Secrets From Developers, use the discussion on Forum.

>> forum community

Comments

Leave a Reply