A creative twist links two tiny packages to a wider web of fake “crypto bot” repos

ReversingLabs researchers noted in a recent blog post that attackers have found a new way to smuggle malicious software to developers: by hiding key instructions inside Ethereum smart contracts. The discovery centers on two npm packages published in July—colortoolsv2 on July 7 and its near-twin mimelib2 later that month—that looked like dull utilities but, once included in a project, quietly reached out for further code that could compromise a machine. Both packages were removed after being reported, yet the story points to something bigger: a coordinated effort across npm and GitHub to make sham “crypto trading bot” repositories look popular and trustworthy long enough to infect curious users.

What happened and why it matters

Npm is the main hub where JavaScript add-ons are shared. Developers, and anyone tinkering with crypto tools or bots, install these add-ons the way you might add a browser extension: you trust the listing, click install, and move on. Most packages are safe. Sometimes, malicious code slips through. In this case, the two flagged packages acted like shells. They contained very little of interest on their own, but when a project ran them, a hidden script phoned home for the next step.

What makes this incident notable is where the “instructions” for that next step lived. Instead of pointing straight at a suspicious website, the attackers stored critical data on the Ethereum blockchain. A smart contract—normally used to run transparent, on-chain programs—was repurposed as a kind of public bulletin board. The package read the data from the contract, learned where to go next, and then downloaded the real payload. That small change removes the obvious red flags defenders often look for, like hard-coded web links inside a package, and replaces them with a perfectly normal-looking on-chain read that blends into crypto-related work.

How the on-chain trick worked

A smart contract is a program that lives on Ethereum. It’s public, it doesn’t need a middleman, and—crucially for attackers—it’s very hard to take down once deployed. In these packages, the initial code was little more than a messenger. It reached out to a specific contract, pulled a piece of data from it, and used that data to fetch additional software from elsewhere on the internet. Think of the smart contract as a sticky note on a lamp post: the note itself isn’t harmful, but it tells you where to meet the person who is.

Security teams often scan packages for suspicious web addresses or commands before they run. By moving those addresses off the package and onto the blockchain, the attackers sidestepped a simple screening step. It’s not the first time criminals have hidden their directions in unexpected places—past campaigns have buried pointers in GitHub Gists or cloud storage like Google Drive and OneDrive, precisely because traffic to popular platforms looks “normal.” Using Ethereum is the same idea with a crypto-native twist.

A quick look back at related npm threats

This isn’t the first time npm has been targeted this year. Back in March, researchers documented packages named ethers-provider2 and ethers-providerz that tried a different tactic: they installed, then silently modified a legitimate local copy of the ethers library to open a remote backdoor. Since that report, more “infostealers,” downloaders and droppers have been spotted on the registry. The July finds (colortoolsv2 and then mimelib2) stood out not because they were complex—they were tiny—but because their clever piece lived off the package, on-chain.

The bait wasn’t the package—it was the GitHub theater around it

The npm listings themselves were sparse and unconvincing. The real lure was a cluster of GitHub repositories dressed up as high-performance trading bots. The flagship was a project called solana-trading-bot-v2, pitched as a plug-and-play tool that could automatically snipe new token listings and manage positions. At first glance it had all the hallmarks of a thriving open-source project: lots of stars, a swarm of forks, active watchers, and an eye-popping commit history.

Look a little closer and the shine wears off. Many of the accounts starring or watching the repository appeared to have been created around the same date in July, with thin profiles and a single throwaway repository containing a bare “Hi there” readme. The commit count ballooned daily, but the changes themselves were often meaningless—for example, repeatedly creating and deleting the license file to make the activity graph look busy. A handful of edits mattered: the ones that slipped the malicious npm dependency into the bot’s files, later swapping colortoolsv2 for mimelib2 after the first takedown.

The pattern didn’t stop with one repository. Sister projects branded as ethereum-mev-bot-v2, arbitrage-bot, and hyperliquid-trading-bot showed similar signs: inflated stars, odd commit activity, and a cast of puppet-like maintainer accounts meant to make the projects feel established. The picture that emerges is less about sophisticated code and more about a marketing campaign for malware—manufactured popularity designed to win trust at a glance.

Why crypto communities are such a tempting target

Crypto tooling moves fast. Builders and traders are constantly experimenting with bots, MEV helpers and arbitrage scripts. A repo that looks active and useful can spread quickly by word of mouth or search. If even a small number of enthusiasts clone the project and run it, the malicious dependency gets a chance to execute, sometimes before anyone has reviewed the details. That’s the essence of a supply-chain attack: you trust a tool, the tool trusts a package, and the package abuses that trust to reach your machine.

This campaign also fits a larger trend. Security firms tracked more than twenty crypto-themed malicious efforts across open-source registries in the last year alone. In December 2024, the popular ultralytics package on PyPI was compromised to deliver a coin miner. In April of this year, researchers flagged another attempt to smuggle a payload into software popular with crypto users. Attackers go where the keys, wallets and exchange credentials are, and the developer ecosystem remains a high-value doorway.

What non-developers should know

You don’t need to read code to grasp the flow. A “downloader” is a tiny first step whose job is to fetch the real threat later. A “command-and-control” server is where an attacker gives instructions and hosts the payload. In this case, the smart contract didn’t deliver the malware itself; it acted like a waypoint, telling the downloader where to head next. The first-step script was intentionally scrambled so its purpose wasn’t obvious. And the reason this evades some simple checks is because reading from Ethereum looks entirely legitimate inside a crypto project.

How the story came to life after the first takedown

When colortoolsv2 was reported and removed, the same malicious behavior resurfaced under mimelib2, which reused the identical smart contract and the same second-stage malware. That quick reappearance is common in registry attacks: once a package gains attention, it is re-published under a new name while the rest of the lure—the GitHub facade—keeps humming. Researchers reported the clone as well, and it too was taken down. The incident prompted a deeper look that connected the dots between the npm stubs and the larger web of misleading GitHub activity.

What to watch for if you’re in the audience for these tools

For web3 readers who don’t write code, the practical guidance is simple and cautious rather than paranoid. Popularity signals on GitHub—stars, forks, commit graphs, and long maintainer lists—can be fabricated. Repositories that suddenly spike with activity or love from many brand-new accounts deserve skepticism. Trading bots that promise instant results with minimal setup are especially attractive bait in this space. And any tool that immediately fetches more software as soon as you run it, particularly from unusual places, should be treated with care.

Security teams and experienced developers will do the deeper work—verifying dependencies, running scans, and auditing behavior—but ordinary users can still reduce risk by favoring projects with a real track record, known maintainers, and external references beyond the repository itself. If something looks too polished for how new it is, or too busy in ways that don’t add up, it’s worth slowing down.

The bigger lesson for the ecosystem

The innovative part of this campaign isn’t a novel piece of malware; it’s the decision to offload sensitive pointers to the blockchain, which makes the package itself look cleaner and makes takedowns harder. Combined with a social-engineering push to make sham repos feel legitimate, the attackers created an efficient funnel from curiosity to compromise. It’s one more sign that open-source registries and code-hosting platforms will keep being used as distribution channels, and that crypto-focused communities remain a prime target.

ReversingLabs’ findings underline a familiar but urgent message: presentation isn’t proof. Stars, forks, and commit counters are easy to game, and a dependency tree can hide more than it reveals at first glance. Whether you build software for a living or just like to try the latest trading toy, treat new packages and repos like unknown tokens—do your own research before you touch them.