Solidity Pro Extensions Steal AI, Cloud, and SSH Credentials from Developer Machines
What happened
Two editor extensions published under the name Solidity Pro - helper-beeps.solidity-pro and web3devtoolsx.solidity-pro, from publisher web3devtoolsx - were distributed through Open VSX and operated as credential stealers. Yeeth Security published the analysis on August 6, 2026, and both listings have since been removed from the marketplace. There is no CVE, which is correct: this is malicious code shipped deliberately, not a defect in a legitimate product. The distinction matters for how you respond, because there is nothing to patch.
The extension's behavior changed across its release history, and the progression is instructive. Versions 1.0.0 through 2.4.x reached out to Cloudflare Workers endpoints, retrieved an encrypted Python payload, and executed it - a loader design, keeping the shipped extension small and the real logic remote and swappable. From version 3.0.0 onward it became a full infostealer carried in the extension itself, with the activation delayed by hours or days after install. Removal from Open VSX does not uninstall anything already on a developer's machine, and the source repository reportedly stayed reachable on GitHub after the listings came down.
What it took
The harvest list is worth reading in full, because it is not a crypto-stealer that happens to also grab tokens. It is a developer-credential stealer that happens to also grab wallets.
| Credential class | Specifics reported | What it unlocks for an attacker |
|---|---|---|
| Source-control tokens | GitHub ghp_ and github_pat_, GitLab glpat- | Repository read and write. A pushed commit becomes trusted context that other developers' agents will read and act on. |
| Cloud credentials | AWS access keys and session tokens, Cloudflare cfat_ tokens | Direct infrastructure access, including DNS and edge configuration where Cloudflare tokens are scoped broadly. |
| LLM provider API keys | OpenAI sk- and sk-proj-, Anthropic sk-ant- | Inference billed to the victim, and the ability to drive agents that already hold repository and cloud access. |
| Host access | SSH private keys | Lateral movement to every host that key reaches, with no further exploitation required. |
| Secondary auth | 1Password MFA tokens, Telegram bot tokens | Undermines the recovery path. A stolen MFA token weakens the control you would otherwise rely on during containment. |
| Wallets | MetaMask, Phantom, Rabby, Coinbase, Trust, Keplr vaults; Bitcoin WIF and xprv keys | Immediate irreversible financial loss, which is likely the direct monetization path. |
Collected data was exfiltrated through a Telegram bot, a choice that costs the attacker nothing to operate and blends into ordinary HTTPS traffic. Reporting also names an associated malicious dependency, @jaymara/jsononifier, so the dependency graph on any affected machine is worth inspecting rather than assuming the extension was the whole of it. The cross-ecosystem pattern here matches campaigns we have covered in the Trapdoor credential stealer across npm, PyPI, and crates and the Hades PyPI and Bun credential stealer, and the broader defensive frame is in AI supply-chain attacks: a defender's guide.
Built to survive review
Three properties of this campaign are aimed squarely at the controls most organizations actually have.
Delayed activation. The 3.x payload fires hours or days after install, once the extension has been used and judged legitimate. A review process that installs a candidate extension, observes it in a sandbox, and approves it is measuring a window the attacker intentionally left clean. This is the same timing attack that makes marketplace approval an insufficient control for agent skills, described in the malicious agent skills advisory, and it is the practical case for why scan-time checks and runtime governance solve different problems.
Signature evasion by design. The analysis reports heavy obfuscation, strings split across IIFE tables and reassembled at runtime, and method names randomized between releases. That last detail is the one to plan around. A hash or signature written against version 3.1 does not match 3.2. Detection has to be behavioral - what does this code reach for, and where does it send it - which is the argument made at length in runtime monitoring and anomaly detection for AI agents.
A plausible name in a real gap. Solidity tooling is a legitimate need, and a developer searching for it in an editor marketplace has no strong signal to distinguish the impostor. This is the install-path problem from a different angle than slopsquatting and hallucinated package installs and the SEO-poisoned fake Claude Code and Gemini CLI installers, but with the same conclusion: the moment of installation is a weak place to put your only control. The campaign also shares tradecraft with the WhiteCobra cluster observed in September 2025, which distributed Lumma Stealer through malicious editor extensions, so the pattern is established rather than novel.
Why this is an agentic-endpoint risk
An editor extension and an AI coding agent live on the same machine, in the same user context, with access to the same files. Everything this stealer targets is what an agent needs in order to work: a GitHub token so it can read and push, AWS credentials so it can touch infrastructure, an LLM provider key so it can call a model, SSH keys so it can reach hosts. Those secrets are in environment variables, dotfiles, and agent configuration precisely because the agent requires them. The extension never has to attack the agent. It reads the keys the agent was handed.
The second-order consequences are the ones that outlast credential rotation. A stolen LLM key means inference on someone else's account, the abuse pattern documented in LLMjacking and stolen-key cost abuse. A stolen source-control token means an attacker can commit content that other developers' agents will later read as trusted repository context, which converts a credential theft into a durable indirect prompt injection foothold. And a stolen 1Password MFA token degrades the control you were counting on during containment. Extensions are one of the eight artifact types we treat as first-class for this reason, alongside the config-drift surface described in the Cursor config surface and MCP drift and the extension inventory question in the most common AI browser extensions.
It is worth noting that this is not the first editor-extension incident to reach agent territory. The Amazon Q Developer VS Code wiper prompt injection and the GitHub Copilot VS Code YOLO-mode RCE both involved a legitimate extension behaving unsafely. Solidity Pro is the other half of the problem: an extension that was never legitimate at all, in the same trust position.
How Anomity surfaces and governs it
Anomity inventories extensions as one of eight AI artifact types its lightweight, unprivileged Endpoint Sensor collects per endpoint, alongside agents, MCP servers, skills, plugins, hooks, CLIs, and secrets. That answers the containment question directly and quickly: which machines have helper-beeps.solidity-pro or web3devtoolsx.solidity-pro installed, at which version, since when. Marketplace takedown does not uninstall anything, so the population of already-affected endpoints is the number that matters, and it is not visible from the marketplace side. If you do not have that view today, how to build an AI agent inventory is the starting point.
Two further capabilities map onto this campaign's specifics. Anomity maintains a secret inventory with values redacted on the endpoint - it records that a credential of a given type exists in a given location, and transmits metadata only over HTTPS, never source code, prompts, or secret values. That tells you the blast radius of an affected machine before you start rotating: which token classes were present to be stolen. And because every added, changed, and removed artifact lands in a queryable 90-day audit trail, the delayed-activation problem becomes tractable from the other direction - you have the install timestamp and version history, so you can bound the exposure window rather than guessing at it. On agents that expose a hook, runtime governance returns allow, deny, or log on tool calls before they run, and violations route to your SIEM, Slack, email, and Jira. Related credential hygiene is covered in secrets management for AI agents and non-human identity governance.
A marketplace takedown removes the listing, not the install. The number that matters is how many of your endpoints still have it.Anomity Threat Research
What to check across your fleet
- Search every endpoint for
helper-beeps.solidity-proandweb3devtoolsx.solidity-proat any version, and remove them locally. Marketplace removal does not uninstall. - Record the installed version. Releases 1.0.0 through 2.4.x fetched a remote payload; 3.0.0 and later carried a full stealer, so the exposure differs.
- On any affected machine, rotate GitHub
ghp_andgithub_pat_tokens, GitLabglpat-tokens, AWS keys and session tokens, Cloudflarecfat_tokens, LLM provider keys (sk-,sk-proj-,sk-ant-), and SSH private keys. Assume everything reachable was taken. - Re-enroll 1Password MFA and revoke Telegram bot tokens found on affected hosts, since these degrade your containment path.
- Inspect dependency graphs for
@jaymara/jsononifierand other packages introduced alongside the extension. - Check for outbound connections to Cloudflare Workers endpoints and Telegram bot API destinations from developer machines, and review any execution of
cscript,mshta,cmd,curl, orpowershelloriginating from an editor process. - Do not rely on hash or signature blocklists alone. Method names were randomized between releases specifically to break them.
- Audit what the stolen credentials did while valid: repository pushes, agent sessions, and inference spend. If that record does not exist, that is the gap to close next, per the AI agent audit trail guide.
- Reconcile the full installed-extension list against what was actually approved, and treat any unreviewed extension on a machine that also runs an AI agent as in scope.
The uncomfortable part of this advisory is that there is no patch to apply and no version to upgrade to. The extension was malicious by intent, it hid its behavior until after approval, and it changed its own fingerprint between releases. What remains is knowing what is installed, limiting what installed code can reach, and being able to reconstruct what happened. This advisory is part of our AI supply-chain attacks and securing AI coding agents and CLIs coverage; if you are working an active case, the AI agent incident response playbook covers the containment sequence. To see every extension, agent, and secret across your fleet in one view, book a 30-minute demo.
Frequently asked questions
Which extensions were malicious, and are they still available?
Two listings published under the Solidity Pro name: helper-beeps.solidity-pro and web3devtoolsx.solidity-pro, from publisher web3devtoolsx. Both were distributed through Open VSX and both have been removed from that marketplace. Removal from the marketplace does not uninstall anything. An extension already installed on a developer machine keeps running until someone removes it locally, and the source repository on GitHub reportedly remained accessible after the listings came down. Yeeth Security published the analysis on August 6, 2026. No CVE was assigned, because this is malicious code rather than a flaw in a legitimate product.
What is delayed activation and why does it defeat review?
Delayed activation means the malicious behavior does not run at install time. In the 3.x releases of this extension, the payload fires hours or days later, after the user has installed it, used it, and concluded it works as advertised. This breaks the assumption behind most approval workflows. A security review that installs an extension in a test environment, watches what it does, and signs off is measuring a window the attacker deliberately left clean. It is the same structural weakness that makes point-in-time marketplace vetting unreliable, and the reason continuous inventory and runtime enforcement matter more than an approval gate.
Why does this matter for AI agent security specifically?
Look at what it steals. GitHub and GitLab tokens, AWS credentials and session tokens, Cloudflare tokens, LLM provider API keys, and SSH private keys are the exact credential set an AI coding agent needs to function, and therefore the exact set sitting in config files and environment variables on any machine running one. A stolen LLM key funds inference on someone else's account and can be used to drive agents that already have repository access. A stolen GitHub token lets an attacker commit code that other developers' agents will read as trusted context. The extension does not need to attack the agent; it just takes the keys the agent was given.
How was the malware hidden from detection?
Three techniques, per the published analysis. Heavy obfuscation throughout. Strings split across immediately-invoked function expression tables and reassembled only at runtime, so the interesting literals never appear intact in the shipped file. And method names randomized between releases, which means any signature written against one version stops matching the next. That last one is the important detail for defenders: this is not a static artifact you can hash and blocklist. Detection has to be behavioral - what does this code reach for, and where does it send it - rather than based on what the file looks like.
What should we do if a developer installed one of these?
Treat every credential reachable from that machine as compromised, not just the ones you can confirm were taken, since the stealer enumerates broadly and exfiltrates in bulk. Remove the extension locally, because marketplace takedown does not uninstall it. Then rotate GitHub and GitLab tokens, AWS keys and session tokens, Cloudflare tokens, LLM provider API keys, and SSH keys, and re-enroll any 1Password MFA affected. Review the machine's dependency graphs for the associated malicious package reported alongside this campaign. Finally, check what the credentials did while valid - agent activity, repository pushes, and inference spend - which is where an audit trail either helps or is conspicuously missing.
