Malicious npm Packages Typosquat ethers, bs58 and bcryptjs

On July 23, 2026, npm security advisories flagged a fresh batch of packages as critical malware, and the most coherent cluster reads like a target list for cryptocurrency theft. The names copy widely used crypto and encoding libraries: ethers-wallet-package, ethers-wallet-packages, ethers-packge, bs58-88, base65-85x, and two packages published under a @bcryptln scope that mimic bcryptjs. Typosquatting a package name is one of the cheapest ways to get malicious code onto a developer machine. Crypto libraries make a high-value target because the payoff is direct. Private keys, seed phrases, and wallet files convert straight into stolen funds.

One caveat up front. At the time of writing, per-package technical detail (exact version numbers, weekly download counts, and command-and-control endpoints) was thin in public reporting for these specific July 23 packages. What follows names the packages from the advisory data and explains the mechanics based on how this class of attack has behaved across 2025 and 2026. Where a specific number or claim comes from a specific researcher, we attribute it.

What happened

A group of npm packages was marked as critical malware on July 23, 2026. The clearest theme is impersonation of cryptocurrency tooling. ethers is one of the most used Ethereum JavaScript libraries, bs58 implements the Base58 encoding that Bitcoin and Solana use for addresses and keys, and bcryptjs is a common password-hashing library. Attackers registered lookalikes: ethers-wallet-package, ethers-wallet-packages, and the misspelled ethers-packge all trade on the ethers name. bs58-88 and base65-85x target the encoding side of the same workflow.

The bcryptjs angle uses a scope trick. Both @bcryptln/bcryptjs and @bcryptln/becryptjs sit under a @bcryptln organization that looks close enough to the real thing to survive a quick glance in a terminal or a pull request diff. A developer copy-pasting an install command, or an AI coding assistant guessing a package name, can pull the wrong one.

The crypto cluster did not arrive alone. The same day's advisories also flagged developer-tooling lookalikes such as vue-demi-fix, fs-extra-core, vitest-axios, eslint-angular-react, and helix-deploy, plus a Packagist entry, intercom-php. Whether every one of these shares an author is not established. What is clear is that the crypto-library subset is the part that puts money at immediate risk.

Why crypto libraries keep getting cloned

Attacks on crypto tooling in npm are not new, and that history is why this batch matters. Socket documented malicious packages impersonating Flashbots SDKs to steal Ethereum wallet credentials in September 2025, and again flagged five packages typosquatting Solana and Ethereum libraries to lift private keys in early 2026. ReversingLabs reported a separate campaign targeting Atomic and Exodus desktop wallets through npm. In June 2026, CYFIRMA described a multi-stage cryptocurrency malware campaign spread across npm with a reported cumulative reach of more than 2.7 million downloads.

The broader base rate is grim. An analysis of Sonatype's 2026 State of the Software Supply Chain report counted more than 454,600 new malicious packages in 2025, pushing the cumulative total blocked past 1.2 million, roughly a 75 percent year-over-year increase. Palo Alto's Unit 42, which has tracked npm compromises through the Shai-Hulud worm and the Miasma family this year, describes a shift from isolated typosquatting incidents to systematic campaigns that weaponize registry trust. Crypto theft is one of the most direct ways to cash out that access.

Who is affected

The people most exposed are developers building on Ethereum, Solana, or Bitcoin who install npm dependencies on machines that also hold wallet keys. That includes dApp and smart-contract engineers, exchange and custody backends, trading bots, and any CI runner that checks out a repo referencing one of these names.

The bcryptjs lookalikes widen the blast radius beyond crypto teams. Authentication code pulls bcryptjs constantly, so a mistyped scope can land in a general web-application backend that has nothing to do with crypto but plenty of secrets worth stealing. If any of these packages reached a build pipeline, treat CI secrets, npm tokens, and cloud credentials on that runner as potentially exposed, not just wallet material.

How this class of attack works

The specific payloads for the July 23 packages were not fully detailed publicly when we wrote this. The mechanics below describe how npm crypto stealers have consistently operated, per the Socket, ReversingLabs, and CYFIRMA reporting cited above, so use them as the model to check against, not as confirmed behavior for every listed package.

The entry point is almost always a lifecycle script. npm runs preinstall, install, and postinstall hooks automatically when a package is added, which means code executes before you ever import anything. A crypto stealer typically does three things in sequence:

• Scans the machine for value. It walks common paths for wallet files (browser extension storage for MetaMask and Phantom, desktop wallet directories for Atomic and Exodus), keystore JSON files, .env files, and anything matching private-key or mnemonic patterns.
• Grabs developer secrets alongside the wallet data. .npmrc tokens, SSH keys, cloud credential files, and GitHub tokens are common secondary targets, because they enable lateral movement and further package publishing.
• Exfiltrates. Older samples posted stolen data to a Telegram bot or a hardcoded HTTP endpoint; recent campaigns favor short-lived command-and-control domains and sometimes stage a second-stage binary through a runtime like Bun to stay off disk.

Some crypto-focused samples add a clipboard hijacker that swaps a copied wallet address for the attacker's, so funds go to the wrong place even if keys are never exfiltrated. This class of behavior is why we keep repeating the same advice about install scripts.

How to check if you are affected

Start with an exact-name search across your projects and lockfiles. Run this from a repo root or a parent directory of several repos:

# Grep every lockfile for the flagged names
grep -REn "bcryptln|ethers-wallet-package|ethers-wallet-packages|ethers-packge|bs58-88|base65-85x|vue-demi-fix|fs-extra-core|vitest-axios|eslint-angular-react|helix-deploy" \
  --include="package-lock.json" \
  --include="npm-shrinkwrap.json" \
  --include="pnpm-lock.yaml" \
  --include="yarn.lock" .

Then ask npm directly what is installed in the current project:

npm ls @bcryptln/bcryptjs @bcryptln/becryptjs \
  ethers-wallet-package ethers-wallet-packages ethers-packge \
  bs58-88 base65-85x 2>/dev/null

Confirm you are pulling the real crypto libraries, not a lookalike. The legitimate names are ethers, bs58, and bcryptjs (no scope). Anything under @bcryptln, or an ethers- prefix with wallet or package in it, is not the upstream project.

If you want to see whether an install script already ran, look for package folders that declared lifecycle hooks:

# Find package dirs that declared install lifecycle scripts
find node_modules -maxdepth 2 -name package.json \
  -exec grep -l "install" {} \;

Remediation

If you find any of these packages, assume code execution already happened on that machine and work from there.

# 1. Remove the package
npm uninstall <package-name>

# 2. Rebuild node_modules from a clean state with scripts off
rm -rf node_modules
npm ci --ignore-scripts

Rotating secrets is the part that actually contains the damage:

• Move any crypto funds to a new wallet generated on a clean device. Keys that touched an infected machine should be considered burned.
• Revoke and reissue npm tokens, GitHub personal access tokens, SSH keys, and cloud credentials that were present on the host or CI runner.
• Rotate application secrets and database credentials reachable from that environment, especially if a bcryptjs lookalike landed in an auth service.

To reduce the odds of a repeat, disable lifecycle scripts by default and allowlist only the packages that genuinely need a native build step. npm 12 now blocks install scripts by default, which closes the most common execution path, but many teams still run older clients in CI:

# Global default for local development
npm config set ignore-scripts true

# In CI, the safe install command
npm ci --ignore-scripts

Pin exact versions in a committed lockfile, require review on lockfile changes, and run software composition analysis so a new dependency name gets a second look before it ships.

FAQ

Is ethers or bs58 safe to use?

Yes. The genuine ethers, bs58, and bcryptjs packages are not affected. The problem is lookalikes with extra words or a fake scope, such as ethers-wallet-package, bs58-88, and @bcryptln/bcryptjs. Install the canonical names, and double-check the exact spelling and scope before running npm install.

How do I know if I installed one of the malicious packages?

Search your lockfiles and run npm ls against the flagged names using the commands above. If a match appears in package-lock.json, pnpm-lock.yaml, or yarn.lock, it was resolved into your dependency tree, even if it came in transitively through another package.

I only installed it in CI, not on my laptop. Am I still at risk?

Treat it as a compromise. CI runners hold npm tokens, cloud credentials, and repository access, all of which are prime targets for this class of malware. Rotate every secret that was available to the job and review the runner's recent outbound network activity.

Why are attackers targeting cryptocurrency developers specifically?

The theft is immediate and hard to reverse. A stolen private key or seed phrase lets an attacker drain a wallet in one transaction, with no chargeback. Researchers at Socket, ReversingLabs, and CYFIRMA have documented repeated npm campaigns aimed at Ethereum, Solana, and desktop wallets for exactly this reason.