Solidity Pro on Open VSX: a 72-hour-delayed wallet and credential heist
# Solidity Pro on Open VSX: a 72-hour-delayed wallet and credential heist
**The next supply chain breach won't come from npm.** It will come from your editor. Two Visual Studio Code-compatible extensions, `helper-beeps.solidity-pro` and `web3devtoolsx.solidity-pro`, sat on the Open VSX registry for weeks doing nothing visible — and then quietly exfiltrated crypto wallet vaults, GitHub tokens, SSH keys, and OpenAI API keys from every developer who had installed them. SlowMist published its detailed version-history analysis on August 19, 2026. The Hacker News first reported the incident on August 10, 2026, drawing on original research by Yeeth Security. Both extensions have since been pulled from Open VSX, but the GitHub repository for one of them remained reachable at publication time — and the techniques map almost one-to-one onto a year of increasingly polished attacks against Solidity developers.
What makes Solidity Pro worth a long read is not the payload itself. It is the patience and discipline of the operation: a randomized 12-to-72-hour activation delay, CI-environment detection, AES-GCM-decrypted payloads fetched from Cloudflare Workers, clean decoy versions interleaved with malicious ones, and exfiltration over Telegram bot uploads. Read the full picture and the uncomfortable truth is that any developer who installs VS Code extensions from public marketplaces without an allowlist is already accepting a risk profile their security team has probably not budgeted for.
The two extension IDs, named precisely
The two extensions share the display name "Solidity Pro" but live under two different publisher namespaces. The full identifiers, as they appeared in Open VSX:
- `helper-beeps.solidity-pro` - `web3devtoolsx.solidity-pro`
Related impostor identifiers reported as part of the same campaign:
- `helper-beeps.solidity-pro-ai-auditor` - `iktok90-design.solidity-pro`
Both primary entries were added to Open VSX's malicious extension control list on August 6 and 7, 2026, according to SlowMist's August 19 write-up. The GitHub repository `web3devtoolsx/solidity-pro` was still accessible as of The Hacker News's August 10 publication. That last detail matters operationally: a reachable repository is an invitation for copy-paste repackaging under a new publisher name.
A versioned timeline of the malware family
Yeeth Security's reconstruction, later corroborated by SlowMist and reported by The Hacker News, traces the evolution across at least eight published versions between the two publisher namespaces.
**Versions 1.0.0 through 2.4.x (`helper-beeps`): dropper era.** The extensions behaved, on the surface, like benign Solidity tooling. After a randomized 12-to-72-hour delay following install, they beaconed to a Cloudflare Workers endpoint — `violet-87cardo[.]workers[.]dev` — fetched an encrypted payload, and launched it via `child_process.spawn` so the resulting process would outlive the extension host. Static scanners that only run an extension for a few minutes never see the network call.
**Version 2.4.1 (`helper-beeps`): environment-aware variant.** This release tightened the trigger. Malicious activity only fired when a `.sol` file or a Hardhat or Foundry workspace was open. It added a 24-to-48-hour delay and probed for continuous-integration environment variables — `CI`, `GITHUB_ACTIONS`, `JENKINS_HOME` — exiting if any were present. When it decided to proceed, it requested encrypted blobs from remote `/firmware` endpoints, decrypted them using AES-GCM, wrote them as a temporary Python file, and launched them in detached mode via Node's `child_process.spawn`.
**Versions 3.0.0 onward: full information stealer.** The dropper discipline gave way to direct theft. The 3.4.0 build under `web3devtoolsx` shipped a `Web3Analytics` module enabled by default that, on VS Code startup or whenever Solidity files were present, scanned the workstation for:
- BIP-39 mnemonics and EVM-format private keys - Browser-stored wallet vaults: MetaMask, Phantom, Rabby, Coinbase, Trust Wallet, Keplr - GitHub and GitLab access tokens - AWS and Cloudflare credentials - SSH private keys - `.env` files - OpenAI and adjacent API keys - Telegram bot tokens
All harvested material was uploaded through a Telegram bot controlled by the attacker — an exfiltration channel that often slips past corporate DLP and egress proxies because Telegram traffic is common and bot uploads are unremarkable.
**Decoy versions.** Between the malicious releases, the publishers pushed clean-looking versions — `web3devtoolsx.solidity-pro` 1.0.0 and 4.0.0 are cited explicitly — that contained no malicious code. A reviewer scanning the marketplace for "anything suspicious" in the latest version would see nothing wrong. Only a full chronological audit of every release surfaced the pattern.
The five evasion techniques, annotated
The discipline visible in this campaign explains why it survived weeks of marketplace scrutiny. Five mechanisms, layered:
1. **Randomized activation delay (12–72 hours).** Any sandbox or marketplace scan that runs the extension for a few minutes never triggers the payload. 2. **CI environment detection.** Variables like `CI`, `GITHUB_ACTIONS`, and `JENKINS_HOME` cause the malware to abort. GitHub Actions, GitLab CI, Jenkins, CircleCI, and most security-vendor sandboxes are all blind to the malicious behavior. 3. **Strings split across IIFE tables.** Encoded strings reassembled at runtime defeat trivial string-based static analysis. 4. **Method name rotation between versions.** Signature-based detections break on every release. 5. **Interleaved decoy releases.** Clean versions rebuild publisher reputation just before a malicious update lands.
Each technique has appeared in isolation in past campaigns. The combination, with this level of patience, is what makes Solidity Pro worth treating as a category rather than an incident.
Blast radius for the individual developer
The damage model is broader than "my wallet got drained." A VS Code extension runs with the user's full context, which on a developer workstation typically means:
- Read access to the open workspace — including `.env` files, local configuration, and any monorepo currently loaded. - Access to `vscode.env.clipboard.writeText`, the editor's first-party clipboard API, which can swap addresses without spawning a child process, opening a network socket, or writing to disk. Yeeth Security documented the same vector in a separate extension, `ethdevtools.solidity-language-support`, in June 2026. - Process persistence via `child_process.spawn`. The detached payload survives the closure of VS Code and continues to run in the background. - Exfiltration over channels that rarely trigger DLP — Telegram bot uploads in particular.
The practical conclusion for any developer who installed either extension: treat the workstation as fully compromised. Hot wallets, long-lived GitHub tokens, SSH keys, and any API key that ever lived in an `.env` file on that machine should be considered exposed.
Detection: copy-paste commands
These commands work across Windows, macOS, and Linux. Run them before uninstalling anything, so the evidence is preserved.
**List every installed extension with its exact version:**
```bash code --list-extensions --show-versions ```
**Filter for any trace of the campaign:**
```bash code --list-extensions --show-versions | grep -Ei "solidity-pro|helper-beeps|web3devtoolsx|iktok90" ```
**Hash known-malicious `extension.js` artifacts on disk (SHA-256):**
```bash # helper-beeps v1.0.0 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-1.0.0/extension.js # expected: 0a9da2b33c94da3f1fc02502ab3caed6e1fbe40f9115422c09103c42a9f8b3d1
# helper-beeps v2.4.1 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-2.4.1/extension.js # expected: da38bd92ead5c3993cce5a940066dd226cbe4c1f3bbfafbeb91e093813479a89
# helper-beeps v3.0.0 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-3.0.0/extension.js # expected: b721113f3e747c38cda0e5a6a1de9b28bf64bd8391d291177a4d3eae5bf0bbc3
# helper-beeps v3.1.0 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-3.1.0/extension.js # expected: 20c2a806619e1f32b3adc78689366959089d1a5de17a59a924bf477284785b5f
# web3devtoolsx v3.4.0 (truncated) sha256sum ~/.vscode/extensions/web3devtoolsx.solidity-pro-3.4.0/extension.js # expected (prefix): 740b461724784e04d6872824904c244016408b30cbbf6c89c069048df9321178 ```
**Find suspicious child processes spawned from the VS Code extension host:**
```bash # Linux / macOS pgrep -af "python" | grep -i "vscode\|extension" # Windows (PowerShell) Get-CimInstance Win32_Process | Where-Object { $_.ParentProcessId -ne 0 -and $_.CommandLine -match "vscode" -and $_.CommandLine -match "python" } | Select-Object ProcessId, CommandLine ```
**Look for known network indicators in local editor logs:**
```bash grep -RE "violet-87cardo\.workers\.dev" ~/.config/Code/logs/ ~/Library/Application\ Support/Code/logs/ ~/AppData/Roaming/Code/logs/ 2>/dev/null ```
**Search for artifacts the payload creates on disk:**
```bash find ~ -type d -iname "*web3analytics*" 2>/dev/null find ~ -name ".firmware" -o -name "firmware.bin" 2>/dev/null ```
**Uninstall the affected extensions:**
```bash code --uninstall-extension helper-beeps.solidity-pro code --uninstall-extension web3devtoolsx.solidity-pro code --uninstall-extension helper-beeps.solidity-pro-ai-auditor code --uninstall-extension itok90-design.solidity-pro ```
Incident response: treat the machine as compromised
Once any of these indicators is confirmed, the response order matters.
1. **Isolate the host.** Disconnect from VPN, cloud consoles, source-control remotes, and any active wallet sessions. Do not start secret rotation from the compromised machine. 2. **Preserve evidence.** Capture the exact extension ID and version, install path, file timestamps, editor logs, unexpected Python processes, and any network alerts before removing files. The IR team will need this to scope which credentials were reachable. 3. **Rotate from a clean machine.** GitHub and GitLab personal access tokens, OpenAI and adjacent API keys, AWS access keys, Cloudflare API tokens, user SSH keys, Telegram bot tokens, BIP-39 mnemonics, and EVM private keys. Assume anything that ever touched the infected workstation is exposed. 4. **Review recent activity.** Look for unusual logins, unexpected Telegram bot uploads, transfers from hot wallets, forced commits, or new SSH keys added to cloud accounts. 5. **Consider a clean reinstall.** Detached payloads may persist outside the extension tree — systemd user services on Linux, LaunchAgents on macOS, scheduled tasks on Windows.
The longer pattern: a year of attacks on Solidity developers
Solidity Pro is the latest in a series. Reading the past twelve months of public reporting, four prior incidents deserve to be remembered because they all informed the techniques used here.
- **March 2026.** StepSecurity documented three IoliteLabs extensions — `solidity-macos`, `solidity-windows`, `solidity-linux` — updated simultaneously to version 0.1.8 after nearly eight years of dormancy. All three embedded a multi-stage backdoor that downloaded platform-specific payloads from attacker-controlled domains. The VSIX for `solidity-macos` had shrunk from 35–40 MB to roughly 2 MB; the Solidity language server had been gutted and replaced with five stub commands. Combined installs were around 27,500. - **June 2026.** Yeeth Security flagged `ethdevtools.solidity-language-support`, a clipboard-based stealer that used `vscode.env.clipboard.writeText` to swap Ethereum addresses in the user's clipboard. No child process, no network call, no disk write — and therefore invisible to most static scanners. - **July 2025.** A fake "Solidity Language" extension on Cursor — the VS Code-based editor that uses Open VSX by default — was tied to the theft of roughly $500,000 in cryptocurrency from a Russian developer. Kaspersky attributed the operation to the PureLogs infostealer, delivered via ScreenConnect for remote access. The malicious extension appeared in Cursor's fourth search position for "solidity," below the legitimate one. - **October 2024.** ReversingLabs and Datadog Security Research documented a wave of VS Code Marketplace extensions delivering obfuscated PowerShell payloads. Datadog tracked the actor as MUT-9332.
Each campaign refined a piece of the playbook. Solidity Pro is what the playbook looks like when someone assembles all the pieces and applies patience.
What an organization owes itself before the next campaign
If the lesson of Solidity Pro can be summarized in one sentence, it is this: the trust model of public extension marketplaces is incompatible with handling high-value secrets on the same workstation. Until that is acknowledged at process level, campaigns like this will keep finding victims.
Practical controls worth defending in any next security review:
- **Extension allowlists.** A catalog of approved publishers and exact extension IDs, enforced via VS Code's policy files or the equivalents in Cursor and Windsurf. - **Centralized inventory.** Collect `code --list-extensions --show-versions` from every developer workstation, version it in the team's configuration repository, and review diffs in code review. - **Quarterly secret rotation.** Treat any persistent token on a developer machine as having a short half-life. Rotate SSH keys, GitHub tokens, and cloud API keys on a schedule, not on incident response. - **Separation of signing machines.** Sign transactions from a dedicated machine or hardware wallet outside the daily-driver workstation. Hot wallets should hold only what is needed for active testing. - **EDR coverage of the extension host.** Detection solutions should be able to attribute child processes to the VS Code binary and flag outbound connections to unclassified cloud domains. - **Manual update approval.** Disable automatic extension updates on sensitive machines and require a human review of every version bump.
The Solidity Pro incident is not a Microsoft problem, not a Marketplace problem, and not a VS Code problem. It is a problem of letting the editor's convenience default override the security team's risk model. Fix that, and campaigns like this one stop finding targets.
IOC summary table
For a fast response in the middle of an incident, indicators of compromise in a single view help. The table below consolidates what Yeeth Security, SlowMist, and Cyber Security News have published.
| Type | Indicator | Notes | |------|-----------|-------| | Extension ID | `helper-beeps.solidity-pro` | Versions 1.0.0–3.2.x malicious; clean releases interleaved | | Extension ID | `web3devtoolsx.solidity-pro` | 3.4.0 infostealer; 1.0.0 and 4.0.0 decoy | | Extension ID | `helper-beeps.solidity-pro-ai-auditor` | Same-campaign impostor | | Extension ID | `iktok90-design.solidity-pro` | Same-campaign impostor | | Domain | `violet-87cardo[.]workers[.]dev` | Cloudflare Worker endpoint, versions 1.0.0–2.4.x | | SHA-256 | `0a9da2b33c94da3f1fc02502ab3caed6e1fbe40f9115422c09103c42a9f8b3d1` | `helper-beeps` v1.0.0 `extension.js` | | SHA-256 | `da38bd92ead5c3993cce5a940066dd226cbe4c1f3bbfafbeb91e093813479a89` | `helper-beeps` v2.4.1 `extension.js` | | SHA-256 | `b721113f3e747c38cda0e5a6a1de9b28bf64bd8391d291177a4d3eae5bf0bbc3` | `helper-beeps` v3.0.0 `extension.js` | | SHA-256 | `20c2a806619e1f32b3adc78689366959089d1a5de17a59a924bf477284785b5f` | `helper-beeps` v3.1.0 `extension.js` | | SHA-256 (truncated) | `740b461724784e04d6872824904c244016408b30cbbf6c89c069048df9321178` | `web3devtoolsx` v3.4.0 infostealer | | Folder | `*web3analytics*` in user home | Default-enabled module in 3.4.0 | | Files | `.firmware`, `firmware.bin` | Decrypted temporary Python payload | | Env var | `CI`, `GITHUB_ACTIONS`, `JENKINS_HOME` | Causes abort if present | | Process | Python child of `Code Helper` or `code` | Spawned via `child_process.spawn` | | Traffic | Uploads to Telegram Bot API | Primary exfiltration channel from 3.0.0 onward |
Why Open VSX is the weakest link
There is one detail of the case that deserves to be highlighted: Solidity Pro was distributed primarily through Open VSX, not the Microsoft VS Code Marketplace. The distinction matters. The Microsoft Marketplace runs a pre-publication review and operates a moderation team with public SLAs. Open VSX, maintained by the Eclipse Foundation as an open registry for VS Code-derived editors (Cursor, Windsurf, VSCodium, Gitpod, Google Cloud Shell Editor), follows a looser model: moderation is post-publication and depends on community reports.
That does not make Open VSX "insecure by design" — it is a deliberate decision to keep the ecosystem open, assuming client editors (Cursor, Windsurf) apply additional controls. But it shifts the cost of detection to every security team, which now has to monitor two marketplaces in parallel. Cursor, additionally, has used Open VSX as its default registry since July 2025, multiplying the exposed surface.
The operational consequence is direct: if your organization allows developers to use Cursor or Windsurf, the extension allowlist has to include Open VSX reviews with the same rigor as Microsoft's. If you only monitor one, attackers already know which one to pick.