Skip to content
Beveiligingsnieuws

Solidity Pro VS Code extensions steal wallets

Solidity Pro VS Code

Cybersecurityonderzoekers hebben a new variant of supply chain misbruik blootgelegd in de vorm van a malicious Visual Studio Code-extension with the name Solidity Pro (“solidity-pro”). Once the extension runs, it can not only collect information, but also steal crypto wallets and sensitive access keys from systems and browsers. What’s striking: the behavior isn’t static—it changes per version, making detection much harder.

The findings focus on extension names such as helper-beeps.solidity-pro and web3devtoolsx.solidity-pro. Although these extensions would no longer be available on Open VSX, the associated GitHub repository is still accessible in any case. That makes it extra important for developers to understand how the supply chain attack works and which steps help limit damage.

What exactly is wrong with Solidity Pro VS Code?

According to Yeeth Security, the extension delivered a range of malicious components. In early versions (roughly from 1.0.0 through v2.4.x), the system is first “woken up” by communicating with Cloudflare Workers. After that, an encrypted Python payload is fetched and executed.

Starting with v3.0.0, it shifts to a more direct approach: an information stealer. That module collects, among other things, browser profiles and various wallet data, plus tokens and keys from multiple sources.

What data can the extension collect?

The haul is broad. Rather than targeting a single specific app, the stealer attempts to access multiple types of credentials—from platform tokens to wallet inventories and developer access.

  • GitHub tokens (for example ghp_ and github_pat_)
  • GitLab tokens (glpat-)
  • AWS keys and session tokens
  • Cloudflare tokens (cfat_)
  • OpenAI API keys (sk-, sk-proj-, and sk-ant-)
  • Telegram bot tokens
  • Mnemonic/seed phrases
  • Wallet vaults from, among others, MetaMask, Phantom, Rabby, Coinbase, Trust, and Keplr
  • Bitcoin-related keys (such as WIF/xprv)
  • SSH private keys (PRIVATE KEY)
  • URL credentials and 1Password MFA tokens

In practice, this means: if the extension is installed on a developer machine or admin workstation, it can “gather” access-related data from both code ecosystems and the way people manage their accounts and wallets.

Exfiltration via Telegram

After collecting the data, the malware exfiltrates the information using an upload mechanism with a Telegram bot. This is relevant for incident response: it enables investigators to look for network- and account-level signals that match Telegram communication originating from development environments.

Why is detection difficult?

One key point from the research is that the malware authors try to bypass the chain of analysis and review. The extension is loaded with heavy obfuscation (encrypted/obscured code structures), which makes static scanners less likely to understand what’s happening.

In addition, the extension could react “on time.” There are reports of random delayed activation: the malicious branch only gets activated hours—or even days—after installation. That way, an automated check that only inspects the package for a short time may miss the real payload.

Finally, the malware may change methods and names per release. As a result, signature-based detection can end up chasing its tail, because the same intent in the code can change between versions.

Comparison with earlier VS Code attacks

The researchers place this incident within a broader pattern. The activity would follow the same general “playbook” as a previously detected threat cluster known as WhiteCobra, which, for example in September 2025, spread Lumma Stealer via malicious VS Code extensions.

This is also not the first time malicious actors imitate Solidity- or Ethereum-like tooling. In June 2026, Yeeth Security already warned about an extension called ethdevtools.solidity-language-support, which pretended to be language support for Ethereum but turned out to contain a delayed clipboard stealer. In that case, BIP-39 seed phrases, private keys, and wallet addresses were manipulated: a well-known crypto address in your clipboard was replaced with one controlled by the attacker.

If you see these kinds of signals returning across different campaigns, that’s a strong indication that it’s a reusable attack pattern within open-source/developer ecosystems.

Other suspicious packages and extensions around the same period

Besides Solidity Pro VS Code, the findings also point to other supply chain variants. For example, a malicious npm package called ascii-fetcher is said to include malicious code via a dependency such as @jaymara/jsononifier. In the example, it would decode and execute an embedded command using Windows-specific mechanisms.

In addition, multiple VS Code extensions are mentioned that would contain Windows-dropper-like scripts, including cases where a postinstall hook is used to fetch and start a payload remotely.

Further, an extension is mentioned with a title like DigitalBarberTrim.html-entity-codec, which may deploy a remote VSIX file in certain versions. Here too, staying “under the radar” is central: in some variants, the stub would look almost empty, while the real action only happens later.

What should you do now if you installed Solidity Pro VS Code?

If you installed Solidity Pro VS Code extensions, the researchers recommend acting quickly. The core steps focus on removing the extension immediately, inspecting the associated code chain, and blocking outbound traffic and abuse indicators.

  • Remove the extensions from your VS Code installation.
  • Inspect dependency graphs: check which packages are installed and whether there are suspicious transitive dependencies.
  • Block known C2 domains (command-and-control), to the extent you can find them in advisories.
  • Watch for system commands that match the misuse, such as cscript, mshta, cmd, curl, and powershell.

Because this attack targets high-value data, it’s also wise to review your accounts and keys. Think about rotating tokens (GitHub/GitLab/AWS/Cloudflare/OpenAI) and resetting wallet access if seed phrases or vault data may have been exposed.

Prevention: how do you reduce the chance of this kind of supply chain damage?

The key takeaway is that “developer tools” aren’t automatically safe. Extensions can have access to your environment and information in your browser and system. That’s why it helps to tighten up your workflow.

  • Install extensions only when you trust the source and understand the functionality.
  • Update your review process: don’t just check imports—also look at runtime behavior and delayed activation patterns.
  • Limit privileges: run development tooling with fewer permissions than you would need for production.
  • Monitor suspicious behavior on your endpoints: unexpected command executions and outbound traffic can be early indicators.

If you want more context on how supply chain and developer workflows are abused, these articles are relevant: CI-workflows hacked via GitHub issues: fix this and In Other News: AI, supply chain, and ports under pressure.

Conclusion

Solidity Pro VS Code is a clear warning that malicious extensions in development environments can quickly grow into a major data breach and theft route. Through obfuscation, version-dependent code changes, and delayed activation, the attack can stay unnoticed for a long time—until the harmful components actually trigger.

Are you a user of these extensions or comparable Solidity/crypto tools? Then remove them, inspect your installations, and take token and wallet rotation into account. That way, what seemed “useful” doesn’t turn into stolen credentials and financial damage.

Source: https://thehackernews.com/2026/08/solidity-pro-vs-code-extensions-steal.html