--- title: "Solidity Pro Extensions Steal AI, Cloud, and SSH Credentials from Developer Machines" description: "Two Solidity Pro extensions on Open VSX harvested GitHub, AWS, Anthropic, and SSH credentials, activating days after install. Both have now been removed." url: "https://anomity.ai/blog/solidity-pro-open-vsx-credential-stealer/" source: html --- On this page - What happened - What it took - Built to survive review - Why this is an agentic-endpoint risk - How Anomity surfaces and governs it - What to check across your fleet - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Solidity Pro Extensions Steal AI, Cloud, and SSH Credentials from Developer Machines ![Anomity robot illustrating Solidity Pro Extensions Steal AI, Cloud, and SSH Credentials from Developer Machines] Advisory Critical # Solidity Pro Extensions Steal AI, Cloud, and SSH Credentials from Developer Machines Anomity Research Anomity Threat Research · Aug 10, 2026 · 8 min read Share: Copied IDE Extensions & Plugins · Critical · Solidity Pro / web3devtoolsx (Open VSX; no CVE assigned) · Aug 10, 2026 Affected helper-beeps.solidity-pro and web3devtoolsx.solidity-pro, versions 1.0.0 through 3.x, distributed via Open VSX (both removed) ## 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](https://anomity.ai/blog/trapdoor-cross-ecosystem-credential-stealer-npm-pypi-crates/) and [the Hades PyPI and Bun credential stealer](https://anomity.ai/blog/hades-pypi-pth-bun-credential-stealer/), and the broader defensive frame is in [AI supply-chain attacks: a defender's guide](https://anomity.ai/blog/ai-supply-chain-attacks-defenders-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](https://anomity.ai/blog/malicious-agent-skills-hidden-payloads-usenix-2026/), and it is the practical case for why [scan-time checks and runtime governance solve different problems](https://anomity.ai/blog/claude-security-scan-time-vs-runtime-governance/). **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](https://anomity.ai/blog/runtime-monitoring-anomaly-detection-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](https://anomity.ai/blog/slopsquatting-hallucinated-package-installs/) and [the SEO-poisoned fake Claude Code and Gemini CLI installers](https://anomity.ai/blog/seo-poisoning-fake-gemini-cli-claude-code-installers-infostealer/), 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, and increasingly they are the same artifact, now that [an agentic IDE like Google Antigravity installs as an extension across four editors](https://anomity.ai/blog/google-antigravity-ide-extensions-agent-inventory/). 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](https://anomity.ai/blog/llmjacking-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](https://anomity.ai/blog/indirect-prompt-injection-explained/) 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](https://anomity.ai/blog/cursor-config-surface-cursorrules-mcp-drift/) and the extension inventory question in [the most common AI browser extensions](https://anomity.ai/blog/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](https://anomity.ai/blog/amazon-q-developer-vscode-wiper-prompt-injection-ghsa-7g7f-ff96-5gcw/) and the [GitHub Copilot VS Code YOLO-mode RCE](https://anomity.ai/blog/github-copilot-vscode-yolo-mode-rce-cve-2025-53773/) 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](https://anomity.ai/blog/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](https://anomity.ai/#outcomes), 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](https://anomity.ai/#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](https://anomity.ai/blog/secrets-management-for-ai-agents/) and [non-human identity governance](https://anomity.ai/blog/non-human-identity-governance-guide/). > 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-pro and web3devtoolsx.solidity-pro at 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_ and github_pat_ tokens, GitLab glpat- tokens, AWS keys and session tokens, Cloudflare cfat_ 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/jsononifier and 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 , or powershell originating 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](https://anomity.ai/blog/ai-supply-chain-attacks-defenders-guide/) and [securing AI coding agents and CLIs](https://anomity.ai/blog/securing-ai-coding-agents-and-clis/) coverage; if you are working an active case, [the AI agent incident response playbook](https://anomity.ai/blog/ai-agent-incident-response-playbook/) covers the containment sequence. An extension does not have to be malicious to be dangerous, either: [BragJack](https://anomity.ai/blog/bragjack-browser-extension-ai-assistant-hijack/) turned ordinary extension permissions into control of the browser's built-in AI agent. To see every extension, agent, and secret across your fleet in one view, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## 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. ## Related [Advisory High ### OpenCode Server Cross-Site Upgrade Installs Attacker Packages - GHSA-632h-h47v-g4x4 A web page could make OpenCode's local server install an attacker's npm package via a cross-site form. No DNS rebinding needed. Fixed in 1.18.22. Anomity Research · Oct 2, 2026 · GHSA-632h-h47v-g4x4 (CVSS 7.5, no CVE)](https://anomity.ai/blog/opencode-cross-site-upgrade-rce-ghsa-632h-h47v-g4x4/) [Advisory High ### Plugin4Shell - A Branch Named Like a Commit Broke Plugin SHA Pinning in Four Coding Agents Plugin4Shell let a plugin owner swap reviewed code under an intact SHA pin. Auto-update made it zero-click. Two agents patched, two never will. Anomity Research · Oct 2, 2026 · Plugin4Shell (AIR, 2026-09-17); no CVE assigned](https://anomity.ai/blog/plugin4shell-coding-agent-plugin-sha-pinning-bypass/) [Advisory Critical ### mcp-atlassian HTTP Auth Bypass Falls Back to Global Credentials - CVE-2026-77254 CVE-2026-77254 (CVSS 9.1): unauthenticated HTTP MCP requests to mcp-atlassian below 0.22.0 fall through to globally configured Jira/Confluence credentials. Sibling CVE-2026-77244 (CVSS 10.0) accepts any non-empty token. Anomity Research · Sep 28, 2026 · CVE-2026-77254 (CVSS 9.1, GHSA-vc8m-84rp-53hx); sibling CVE-2026-77244 (CVSS 10.0, GHSA-wrhw-j3f9-8vc6)](https://anomity.ai/blog/mcp-atlassian-http-auth-bypass-global-credentials-cve-2026-77254/) ## Structured data ```json { "@context": "https://schema.org", "@type": "TechArticle", "headline": "Solidity Pro Extensions Steal AI, Cloud, and SSH Credentials from Developer Machines", "description": "Two Solidity Pro extensions on Open VSX harvested GitHub, AWS, Anthropic, and SSH credentials, activating days after install. Both have now been removed.", "datePublished": "2026-08-10", "dateModified": "2026-08-10", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/solidity-pro-open-vsx-credential-stealer/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/coding-agents.jpg", "width": 1200, "height": 630 }, "articleSection": "IDE Extensions & Plugins", "url": "https://anomity.ai/blog/solidity-pro-open-vsx-credential-stealer/", "keywords": "Solidity Pro extension credential theft, Solidity Pro / web3devtoolsx (Open VSX; no CVE assigned), Solidity Pro, Open VSX, IDE extensions, credential theft, infostealer, supply chain, delayed activation, WhiteCobra" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Which extensions were malicious, and are they still available?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "What is delayed activation and why does it defeat review?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "Why does this matter for AI agent security specifically?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "How was the malware hidden from detection?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "What should we do if a developer installed one of these?", "acceptedAnswer": { "@type": "Answer", "text": "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." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Solidity Pro Extensions Steal AI, Cloud, and SSH Credentials from Developer Machines", "item": "https://anomity.ai/blog/solidity-pro-open-vsx-credential-stealer/" } ] } ```