Between July 26 and August 1, 2026, our monitoring systems identified 77 Open VSX extensions that beacon to the same newly registered domain. Each one republishes the name, namespace and description of a real VS Code Marketplace extension at a low version number, almost always 0.0.1 , under an account that does not own the namespace and does not belong to the original author [ example 1 , example 2 , example 3 ].
The bundled extension.js is swapped for a beacon. In most of the packages it sends little more than the machine's hostname. In nineteen of them it sends a detailed description of the machine, the repository open in the editor, and the CI system the editor is running inside. The Open VSX listings described this under a section headed “Telemetry.”
As of August 3, 2026, these packages have been removed from Open VSX. However, the infrastructure they is still up.
77 counterfeit extensions hit Open VSX in a week , each copying a real VS Code Marketplace extension's name and namespace from a pseudonymous account, all beaconing to a domain registered eleven days earlier. Nineteen carry a full reconnaissance payload; the rest send little more than a hostname.
Those nineteen profile an organisation, not a machine : git remote host and org, commit email domain, workspace path, branch, HEAD commit, CI project identifiers. On a build runner, that is the private repository path outright.
The listings called it "Telemetry" and got one thing wrong. They said CI values never leave the machine. The code sends them.
Name resolution is now automated. Agents, devcontainer configs and provisioning scripts install by name across two registries with separate ownership rules, and a squatted name on one is indistinguishable from the real one on the other.
Anthropic's July 30 disclosure showed a name is all it takes. One of its models published a PyPI package under a name that existed only in a fictional document; fifteen real systems executed it within the hour.
Check what your fleet actually installed , not just what your configs request. Full list with VSIX hashes below.
The 77 samples are not identical, and it is more useful to think of them as a capability spectrum than as two clean families. Data breadth and delivery resilience vary independently across the set. But they fall into two rough groups.
Fifty-eight are lightweight. Between roughly 1.6 and 3.3 KB, sending the hostname and sometimes the workspace folder name or editor version, along with a per-package tracking identifier. Delivery varies: some POST to /api/v1/metrics or /api/v1/events , some use a GET query string, some carry the full multi-endpoint failover logic described below. What stays constant is that the data collected is minimal. This is the bulk of the campaign.
Nineteen are reconnaissance payloads. Around 10 KB, and considerably more thorough. Four to five seconds after activation one of these assembles a single request containing the local hostname and OS username, the editor's name, version, host kind and machine ID, the platform and architecture, the locale and timezone, and the open workspace's folder name and full filesystem path.
Then it reads .git . From config it takes the remote URLs for origin and upstream and reduces each to host plus organisation, and it takes the domain portion of the configured commit email. From HEAD and the ref files it takes the current branch and the HEAD commit SHA. It enumerates up to sixty installed extension IDs and picks up the proxy hostname from the environment. From the CI environment it takes two things: the names of any CI markers present, and separately the values of GITHUB_REPOSITORY , CI_PROJECT_PATH , the Azure DevOps collection URI, the Buildkite organisation slug, the CircleCI project username, the Codespace name and the Gitpod workspace context URL. On a build runner or a cloud development environment, that is the full private repository name, not just the organisation.
It also reads the editor's own telemetry opt-out setting, records whether it is enabled, and sends regardless.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
