Last updated: June 30, 2026
The most dangerous supply chain attacks are not always the loud ones.
Over the last few days, Pluto Security has been tracking an active malicious extension campaign on Open VSX. We are calling it Count Dooku because the campaign’s core trick is borrowed legitimacy: familiar extension names, copied upstream metadata, credible repositories, and small malicious changes that are easy to miss during a fast review.
The campaign is still under investigation, and we will continue updating this blog as we confirm additional packages, infrastructure, and impact.
Our current list contains 58 campaign-linked Open VSX versions published between June 26 and June 30, 2026 UTC. Of those, 43 versions contain direct indicators tied to the observed beststats.world payload, while 15 currently available versions match the same campaign pattern but did not contain the observed payload at review time.
The campaign spans ordinary developer utilities and AI/LLM-adjacent tooling. Campaign-linked names include extensions related to DeepSeek, Gemini, Cursor AI, Doubao, Claude, OpenRouter, Ollama, Kimi, CodeBuddy AI, Cline, Text2Code, MarkItDown, and Google Colab, alongside non-AI developer extensions such as document viewers, Markdown tooling, SQL tooling, file icons, Playwright test tooling, theme packages, and preview utilities.
The campaign appears to rely on republishing or copycatting legitimate VS Code-compatible extensions into Open VSX. In many cases, the packages claim an upstream repository belonging to a legitimate project, while the Open VSX publication is associated with an unrelated account or an unverified namespace.
In the best-understood samples, the malicious change is small and direct: an extra JavaScript block is appended to the packaged extension code. The legitimate extension logic remains mostly intact, which helps the package appear normal during casual use and makes quick source comparisons less reliable.
The injected code creates a persistent local identifier and sends a beacon to attacker-controlled infrastructure.
Observed network indicator:
https://beststats[.]world/pingObserved local artifact:
~/.vsx-idThe observed payload sends a small set of host and package metadata, including a generated ID, platform, publisher/name/version metadata, and then suppresses errors. At this stage, the payload we reviewed is best described as tracking and reconnaissance, not a full infostealer.
In the Playwright Test Runner sample, the Open VSX package also changed package.json activation from ["*"] to ["onStartupFinished"]. In practical terms, the appended beacon still runs automatically, but waits until VS Code has finished startup.
VS Code-compatible extensions execute inside developer environments, often with access to workspaces, terminals, configuration, and developer credentials. A campaign that can repeatedly publish working copycat extensions can later ship more invasive payloads through the same path.
The infrastructure timeline was one of the first clues. RDAP registration data shows beststats.world was registered on June 26, 2026 at 15:18:53 UTC, shortly before the first affected Open VSX publications in our current list. That does not prove attribution by itself, but it fits the pattern of purpose-built campaign infrastructure appearing just in time for the publishing wave.
Open VSX also surfaced a useful warning on several pages: the version was published by an account that was not a verified publisher for the extension namespace. For example, the Playwright Test Runner package appeared under the sakamoto66 namespace but was published by bennett-charles2788. Pokemon Pets appeared under the AnasFiguigui namespace but was published by bevans42953.
After our initial reporting and the first removals, we also observed the campaign continue in a more staged form. A later confirmed-available sweep identified 16 Open VSX versions still available with the same campaign shape: restricted namespace warnings, unrelated publishing accounts, startup-capable activation, and package or metadata drift from the claimed upstream projects. In that set, 15 versions did not contain the observed beststats.world payload at the time of review. We are treating those as campaign-linked staged artifacts rather than direct beaconing samples.
The CSV to Table case shows why these staged artifacts still matter. The Visual Studio Marketplace page points to a long-standing extension published by Andrew Armstrong, while the Open VSX version appeared under the phplasma namespace but was published by matthew-walker-9276, triggering the Open VSX namespace warning.
Pokemon Pets is another useful example of the campaign evolving in public. Version 1.3.0 contained the observed payload, while Open VSX later showed version 1.3.1 from the same unrelated publisher account. That newer Open VSX version did not match the upstream release line we reviewed and did not contain the same added payload.
One caution on impact numbers: we are treating Open VSX download counts for this campaign as inflated exposure signals, not confirmed malicious install counts. Several affected pages showed large counts despite brand-new unrelated publisher accounts and no review history, so those numbers should not be read as a direct count of infected machines.
This campaign is effective because it does not need to invent trust. It borrows it.
The attacker-controlled packages can look convincing because they reuse:
In one sample we analyzed, the malicious code was appended after the normal bundled output and was not represented in the source map. That is exactly the kind of change a developer can miss if they only skim the README, the manifest, or a small section of bundled JavaScript.
There were still red flags. Open VSX metadata exposed signals such as unverified namespaces, unrelated publishing accounts, and publication timestamps that did not line up with upstream release history. Those signals become much more powerful when paired with package-content comparison.
This campaign is not exclusively an AI-extension campaign. The affected list includes many general-purpose developer tools.
But AI and LLM tooling is clearly part of the target set. The campaign includes extension names related to DeepSeek, Gemini, Cursor AI, Doubao, Claude, OpenRouter, Ollama, Kimi, CodeBuddy AI, and MarkItDown. These names matter because developers are rapidly adopting AI coding tools, model routers, local LLM runtimes, and IDE assistants, often from extension marketplaces and often with limited provenance review.
That adoption creates a broad target surface: productivity tooling that runs close to source code, terminals, credentials, and build workflows.
Based on the samples analyzed so far, the observed payload:
~/.vsx-id.beststats[.]world/ping.We have not confirmed, from the current payload, direct theft of source code, browser data, cloud credentials, SSH keys, or tokens. However, affected machines should still be treated seriously because extension execution occurs in a sensitive developer context and the campaign has demonstrated the ability to distribute modified packages through Open VSX.
If you installed any affected extension from Open VSX during the campaign window, treat the machine as potentially exposed until reviewed.
Immediate steps:
~/.vsx-id if present.beststats.world or beststats[.]world/ping.For teams operating internal developer environments:
beststats.world.beststats[.]world
https://beststats[.]world/ping~/.vsx-idbeststats.world/ping
path.join(os.homedir(), ".vsx-id")
appended JavaScript IIFEThis is a live investigation. We are continuing to validate package relationships, publisher accounts, infrastructure, and downstream exposure. As we confirm more details, we will update this post with additional technical analysis and detection guidance.
