- A malicious extension named Solidity Pro steals browser wallets and credentials.
- 77 counterfeit extensions on Open VSX impersonate legitimate tools and exfiltrate data.
- Both campaigns use obfuscation and delayed activation to evade detection.
- Users should verify publishers and monitor extension activity.
The Visual Studio Code ecosystem is under siege from a new wave of malicious extensions that target developers’ credentials, crypto wallets, and sensitive repository data. Security researchers have uncovered two distinct campaigns: one delivering a full-fledged information stealer through a fake Solidity tool, and another that flooded the Open VSX registry with counterfeit extensions designed to harvest git and CI/CD metadata. Both campaigns leverage sophisticated obfuscation and delayed activation to slip past automated scanners and build trust with unsuspecting users.
While the extensions have been removed from official marketplaces, the threat persists for anyone who installed them or has them baked into development images. The incidents highlight a growing supply-chain risk in the developer tooling space, where malicious actors exploit the trust developers place in open-source extensions. Organizations and individual developers must take proactive steps to audit their environments and enforce strict extension policies.
The Solidity Pro Stealer
Cybersecurity firm Yeeth Security has flagged a malicious VS Code extension named Solidity Pro (publisher IDs: helper-beeps.solidity-pro and web3devtoolsx.solidity-pro) that delivers a browser wallet and credential stealer. Although the extensions are no longer available on Open VSX, the GitHub repository for web3devtoolsx/solidity-pro remains accessible. Early versions (1.0.0 through 2.4.x) beaconed to Cloudflare Workers endpoints to retrieve and execute an encrypted Python payload. Starting with version 3.0.0, the extension evolved into a full-blown information stealer capable of collecting browser profiles, crypto wallets, source-control tokens, API keys, SSH keys, and Telegram bot tokens.
The stealer harvests a wide range of sensitive data, including GitHub tokens (ghp_ and github_pat_), GitLab tokens (glpat-), AWS keys and session tokens, Cloudflare tokens (cfat_), OpenAI keys (sk-, sk-proj-, sk-ant-), Telegram bot tokens, mnemonic and seed phrases, wallet vaults from MetaMask, Phantom, Rabby, Coinbase, Trust, and Keplr, Bitcoin WIF/xprv keys, SSH private keys, URL credentials, and 1Password MFA tokens. All captured data is exfiltrated via a Telegram bot upload, giving attackers real-time access to the stolen information.
The malware family is designed to bypass marketplace review, static scanning, and casual sandboxing through heavy obfuscation, intermediate clean versions to build trust, and randomized delayed activation. Malicious code runs several hours or days after installation, by which time the user has already decided the extension is useful and automated scanners have moved on. Yeeth Security noted that the obfuscation splits strings across IIFE tables, reassembles them at runtime, and switches method names between releases, making signature-based detection a moving target.
This activity shares the same high-level playbook as WhiteCobra, a threat cluster detected in September 2025 that distributed Lumma Stealer through malicious VS Code extensions. It also follows a June 2026 incident where another extension named ethdevtools.solidity-language-support impersonated a Solidity language-support tool but harbored a delayed-activation clipboard stealer to scrape BIP-39 seed phrases, Ethereum private keys, and wallet addresses. That stealer swapped clipboard addresses with attacker-controlled ones using vscode.env.clipboard.writeText, a first-party API call that requires no child_process, network access, or file writes, thus evading static scanners that only look for dangerous Node imports.
Counterfeit Extensions on Open VSX
In a separate but related development, Manifold Security published research on August 4 revealing 77 counterfeit extensions that appeared on Open VSX between July 26 and August 1. These extensions republished the name and namespace of legitimate VS Code Marketplace extensions from accounts that did not own them. All 77 beaconed to a single domain registered 11 days before the first package surfaced, and most sent only a hostname. However, 19 of them carried a fuller payload that collected detailed information about the developer’s machine and repository.
Within seconds of activation, the malicious extensions sent the hostname, OS username, editor details, and machine ID. They then read the repository open in the editor, capturing the git remote host, organization, commit email domain, branch, and HEAD commit. They also collected continuous integration values such as the GitHub repository name, GitLab project path, and Codespace name. On build runners or cloud development environments, this could reveal the full private repository name, not just the organization.
What made this campaign unusual is that the extensions’ listings included a “Telemetry” section that accurately enumerated most of the collected fields, along with assurances that no source code, credentials, or tokens were taken. Manifold Security verified these claims against the code and found them to hold—except for one extension. That extension’s listing stated that CI data covered marker names only and never values, but the code sent both, making it the single most sensitive field in the payload.
The extensions had no other functionality—a status bar item rendered a checkmark, one command displayed a message box, and the beacon fired. The collector domain was registered through a registrar that redacts registrant details, on a three-year term. The code treated any HTTP response as success, including errors, and retried across seven days, resuming on every editor restart. If all endpoints failed, the beacon queried a DNS TXT record for a replacement collector address, allowing the operator to relocate infrastructure without shipping new packages.
Open VSX removed the packages on August 3, but the infrastructure remained live at the time of writing. Manifold Security advised 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.
Other Malicious Extensions and Packages
The Solidity Pro discovery coincided with the identification of several other rogue VS Code extensions and npm packages. An npm package called ascii-fetcher embeds malicious code in a dependency named @jaymara/jsononifier to decode an embedded command (in the observed case, “calc.exe”) and run it via child_process.exec with windowsHide. A set of 10 VS Code extensions deliver a wide range of Windows-based BAT, JavaScript, and HTA droppers, with two of them bundling an npm dependency that uses a postinstall hook to fetch and execute a remote payload.
Another extension, DigitalBarberTrim.html-entity-codec, drops a remote VSIX file in select versions after enumerating known VS Code forks like Cursor, Windsurf, Codium, and Positron, while serving a “nearly empty stub” in others to fly under the radar. Zlmiles.zlmiles-liquid, now removed from the VS Marketplace, uses a suspected builder kit to drop an MSI installer hosted on a Replit domain. These examples illustrate the diverse tactics attackers employ to infiltrate developer environments.
Protection and Mitigation
Users who have installed any of the flagged extensions are advised to remove them immediately, inspect dependency graphs, block known command-and-control (C2) domains, and alert on use of cscript, mshta, cmd, curl, and powershell commands. Organizations should run code –list-extensions –show-versions to inventory installed extension IDs and versions, and also inspect .vscode/extensions.json, .devcontainer/devcontainer.json, and developer or CI images because automated provisioning can install extensions without a developer manually selecting them.
Marketplace takedowns do not remediate systems where an extension is already present. Teams investigating these campaigns should check affected package IDs, review editor traffic involving mangorbitcom, and inspect endpoints or build environments where suspicious extensions ran. Treating extensions as supply-chain dependencies is crucial—organizations should reject packages from unverified Open VSX publishers, use internal mirrors with known publishers and versions, and leverage Microsoft’s extensions.allowed policy to control permitted publishers, extensions, versions, and platforms.
Extension inventories, publisher verification, allowlists, and endpoint monitoring should be routine wherever developer systems can access source code, cloud resources, or deployment infrastructure. The recent incidents underscore that even trusted tools can become vectors for attack, and vigilance is essential.
As the developer tooling ecosystem continues to grow, so does the attack surface. The Solidity Pro stealer and the Open VSX counterfeit campaign are just two examples of how malicious actors are adapting their methods to exploit the trust developers place in extensions. By staying informed and implementing robust security practices, developers and organizations can reduce their risk and protect their valuable code and credentials from falling into the wrong hands.
