Malicious npm packages stole crypto wallet keys and sent them to Telegram, putting Solana and Ethereum developers at risk

Security researchers have identified five malicious npm packages that target cryptocurrency developers and steal private wallet keys. Socket says the packages were published under the npm account galedonovan and were designed to look like legitimate libraries used in Solana and Ethereum development.

The campaign matters because the packages do not visibly break the victim’s code. Socket says each package hooks into functions that developers routinely use for wallet operations, sends the secret key to a hardcoded Telegram bot, and then returns the expected result so everything appears normal.

Four of the packages target Solana workflows by intercepting Base58 decode() calls, which developers often use when loading keypairs from private key strings. The fifth targets Ethereum by hooking into the Wallet constructor when a private key gets passed in. In both cases, the key is exfiltrated as plaintext before the legitimate operation finishes.

Socket says the command-and-control channel was still active as of March 23, 2026. It also says one package, base_xd, was unpublished within five minutes of going live, while the other four remained live at the time of its March 24 write-up.

The packages researchers linked to the campaign

Socket says all five packages used the same hardcoded Telegram bot token and the same chat ID, which strongly ties them to a single campaign.

How the theft worked

According to Socket, the attacker did not need a second-stage server or custom domain. The packages simply made a fetch() call to Telegram’s Bot API with the stolen key in the message body. That gave the threat actor a direct exfiltration path that would keep working as long as the Telegram bot stayed online.

Socket says the bot and receiving group were live when researchers checked them. The report identifies the bot as @Test20131_Bot and says the same bot token and chat ID appeared across every package in the campaign.

The attack also used stealthy packaging choices. Socket says bs58-basic contained no malicious code of its own and instead relied on base-x-64 as its only runtime dependency. That means a developer could miss the real threat if they only reviewed direct dependencies.

One technical detail makes the malware slightly narrower than it first appears. Socket says all five packages call fetch() as a global without importing it, so exfiltration works on Node.js 18 or later. On older Node runtimes, the call throws an error that gets caught silently, which means the theft fails without warning the victim.

Why crypto developers faced the biggest risk

These packages were not generic malware. They were designed to intercept the exact kinds of functions that handle wallet secrets in real crypto development workflows. For Solana, that meant Base58 decoding. For Ethereum, that meant wallet construction from a private key string.

That design makes the threat especially dangerous because the victim may never see a crash, failed install, or broken output. Socket says the packages behave as expected after stealing the key, which means developers could unknowingly keep using compromised wallets until funds disappear.

What developers should do right now

• Audit projects for raydium-bs58, base-x-64, base_xd, bs58-basic, and ethersproject-wallet.
• Treat any private key passed through those packages as compromised. Move funds and rotate keys immediately.
• Replace them with legitimate packages such as bs58, base-x, and the scoped @ethersproject/wallet.
• Check transitive dependencies, not just top-level entries, because bs58-basic can infect through base-x-64.
• Review build and runtime environments for suspicious outbound calls to Telegram’s Bot API. This last step is an inference based on the exfiltration method Socket documented.

What stands out in this campaign

The strongest sign of coordination is reuse. Socket found the same Telegram infrastructure, overlapping typos, matching package metadata patterns, and identical compiled files across some of the packages. That points to one operator or one tightly controlled campaign rather than unrelated malicious uploads.

The campaign also shows why open source supply chain attacks keep working. Attackers no longer need to break the victim’s app to steal secrets. They can slip into familiar package names, hook a trusted function, and let the software keep running.

FAQ