Recent disclosure of the “Solana FakeFix” campaign exposes a coordinated supply-chain attack that abused package registries to steal developer secrets.
The campaign comprises 16 malicious npm packages and 4 PyPI packages (25 packages in total when combined with related activity) that impersonated Solana tooling, lodged typosquatted names, and used install- and import-time execution to harvest wallet keys, cloud credentials, source-control tokens, SSH keys, and environment secrets.
Attackers leveraged social engineering and developer pain points. Several npm packages mimicked legitimate Solana ecosystem names examples include variants like @solana-labs/web3.js, @solana-labs/spl-toke, solana-web3-stable, and solana-rpc-client positioning themselves as “stable-build” fixes or community forks.
The threat actor even used GitHub issue spam under the account PassWord1337 to promote a drop-in replacement, suggesting an npm uninstall/install command to switch packages.
That lure specifically targeted maintainers struggling with dependency friction, increasing the likelihood that developers or CI pipelines would execute installation workflows that trigger malicious lifecycle hooks.
Initial delivery relied on npm postinstall scripts and PyPI import-time code. Early npm variants simply ran attacker-controlled JavaScript during installation via a postinstall hook no runtime import needed while the Python variants placed payloads in _init_.py so a plain import could begin collection and persistence.
Collected artifacts targeted typical developer secrets: Solana keypairs (~/.config/solana/id.json, ~/.solana/id.json), wallet files, .env files, SSH private keys, AWS credentials, and environment variables with names like KEY, SECRET, MNEMONIC, TOKEN, AWS, GITHUB, or CI.
Exfiltration was realized through Telegram C2 channels with hard-coded bot tokens and chat IDs; later variants supported interactive backdoor commands (e.g., /keys, /ssh, /env, /wallet, /sh, /cmd, /die), sandbox checks, token validation and self-update mechanisms.
JFrog Security Research recently identified Solana FakeFix, a campaign of 20 malicious npm and PyPI packages that target Solana developers.
The campaign evolved from crude backdoors to trojanized libraries. Later npm packages shipped largely legitimate-looking Solana JavaScript bundles with malicious code appended after normal exports and source-map markers making the packages appear useful during casual testing while maintaining stealthy stealer paths.
Solana FakeFix Campaign
One variant attempted RPC tampering and fund draining by reconfiguring Solana RPC endpoints and sending funds to an attacker-controlled address.
The actor opened nine issues across different projects, presenting @solana-labs/web3.js as a community-maintained drop-in replacement for @solana/web3.js v2.
Another package, solana-mev-bot, used classic crypto social-engineering: it presented itself as an MEV bot and asked users to paste private keys, directly capturing the credential needed to drain accounts.
JFrog’s report also details a separate but related CMS Windows loader campaign consisting of five npm packages uploaded by the account thermonuclear.
Those packages used install-time hooks to drop and execute PowerShell scripts, install or invoke Deno, fetch remote JavaScript, and launch Windows-oriented loaders or EXE droppers.
Search logs for Telegram API traffic, suspicious RPC redirects, Deno executions from the documented host, and EXE download URLs.
The loader design supports dynamic second-stage payload retrieval, Registry Run-key persistence, and communication with a remote C2 server, enabling the operator to rotate payloads while keeping the package-side loader unchanged.
Remediation must be aggressive: remove affected packages from developer workstations, CI images, and internal caches; audit and rotate any potentially exposed Solana wallets and keypairs; rotate SSH keys, cloud access keys, and tokens; and rebuild compromised CI runners from trusted images rather than relying solely on package removal.
Finally, apply stricter registry hygiene: treat install-time network access and lifecycle scripts as high-risk, scrutinize near-miss package names, and require provenance and maintainership checks for critical SDK dependencies.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
