Five Malicious npm Packages Target Crypto Developers, Steal Wallet Keys via Telegram
Five malicious npm packages impersonating popular crypto libraries are stealing wallet keys from Solana and Ethereum developers and exfiltrating them directly to a hardcoded Telegram bot.
Each package typosquats or wraps a legitimate crypto library and funnels stolen private keys to the same Telegram bot-based command-and-control (C2) channel.
The campaign hits both Solana and Ethereum ecosystems, and the Telegram C2 infrastructure remained active as of March 23, 2026.
One package, base_xd, was published and then unpublished within five minutes. However, its obfuscated payload and C2 configuration match those used in the still-live base‑x‑64 package.
Socket identified five malicious npm packages published by the account “galedonovan”: raydium‑bs58, base‑x‑64, bs58‑basic, ethersproject‑wallet, and base_xd, all explicitly targeting cryptocurrency developers.
Socket has submitted takedown requests for all five packages and the associated npm account, but at the time of analysis, four remained available in the registry.
Malicious npm Packages
The malicious logic is injected where developers normally handle private keys, ensuring that application behavior appears normal while secrets are silently exfiltrated.
In the four Solana-focused packages (raydium‑bs58, base‑x‑64, bs58‑basic, base_xd), the code intercepts Base58 decode() calls that are typically used to load Solana keypairs from secret key strings.
galedonovan profile showing five published packages. Right: npm registry metadata for base_xd showing publication at 19:03:24Z and an unpublished record at 19:08:30Z – five minutes later (Source : Socket).On the Ethereum side, the trojanized ethersproject‑wallet package triggers inside the Wallet constructor as soon as a private key is passed.
In both cases, the plaintext key is sent to a Telegram group before the legitimate decode or wallet creation completes, letting the attacker immediately import and drain the wallet.
All packages rely on the global fetch() API without importing it, meaning exfiltration only works on Node.js 18+; on older runtimes, a ReferenceError is thrown and silently caught, causing the theft to fail without any obvious error.
All five packages send stolen keys to the same Telegram Bot API endpoint, using a hardcoded bot token and chat ID in every payload.
getChatAdministrators response queried using the bot token hardcoded in the malware (Source : Socket).The bot (@Test20131_Bot) posts messages into a small Telegram group (“My_Bot_Test”) whose creator uses the handle @crypto_sol3, providing a direct attribution link to the operator.
There is no secondary infrastructure or staging server, so as long as the Telegram bot remains active, the exfiltration channel remains operational.
In the simplest package, raydium‑bs58, the entire malicious behavior is a modified decode() function that calls sendMessage(inputKey) before delegating to the real bs58.decode.
The developer accidentally left a comment in the published code containing the full bot token and group invite URL, which exposed the C2 setup without any need for deobfuscation.
Per-package technical notes
raydium‑bs58 re‑exports bs58 with a wrapper decode() that always sends the input key to Telegram first, while copying the README from the legitimate Raydium SDK to appear trustworthy.
The base‑x‑64 package embeds an obfuscated payload in src/cjs/index.cjs that uses an array-rotation cipher and a checksum loop to hide the Telegram URL, bot token, and chat ID before calling fetch() to POST the stolen key. bs58‑basic contains no malicious code itself but depends only on base‑x‑64, so any decode() call on its exported object triggers the exfiltration transitively through that dependency.
The ethersproject‑wallet package clones the real @ethersproject/[email protected] release almost verbatim, injecting a single malicious line into the compiled CJS output while leaving the ESM build clean and the version metadata inconsistent, a clear forensic artifact.
Unlike the others, its error handler logs “Error sending message to Telegram:” to the console, leaving a visible string that can be searched for during audits. base_xd, briefly published then removed, uses the same obfuscation pattern and byte‑identical CJS as base‑x‑64, effectively acting as the original template for the campaign.
Attribution artifacts and defenses
Across all five packages, Socket notes shared typos in package.json (“crytography” and “git diff –exidt-code”), identical compiled CJS binaries, the same Telegram C2 configuration, and uniform file timestamps, strongly indicating a single developer workflow.
Socket highlights that its GitHub App, CLI, Firewall and MCP integrations are designed to catch these supply chain threats flagging typosquatted packages, unexpected network calls, obfuscated payloads, and risky dependency changes before they land in production code.
For developers, the guidance is to immediately remove raydium‑bs58, base‑x‑64, base_xd, bs58‑basic, and ethersproject‑wallet if present, treat any keys passed through them as compromised, and migrate to the legitimate bs58, base‑x, and scoped @ethersproject/wallet packages.
Security teams are urged to scrutinize thin wrapper packages that re-export cryptographic primitives, treat obfuscation in key-handling utilities as a high-risk signal, and closely inspect transitive dependencies that may pull in malicious code indirectly.