Solana web3.js npm Compromise 2024: How a Phished Publishing Account Shipped a Private Key Stealer

On 3 December 2024, an attacker published two malicious versions of @solana/web3.js, the widely used JavaScript library for building on the Solana blockchain, to the npm registry. Versions 1.95.6 and 1.95.7 carried code that sent private keys to an attacker-controlled server whenever an application loaded or created a keypair. According to Anza, the Solana engineering firm that maintains the library, the attacker got publishing rights by spear phishing a member of the @solana npm organisation, capturing their username, password and two-factor code on a fake npm site. The bad versions were live for about five hours, from 3:20pm to 8:25pm UTC. Bots and backend services that handle private keys directly were at risk; non-custodial wallets were not. Helius Labs CEO Mert Mumtaz put early losses at about $130,000. The flaw is tracked as CVE-2024-54134, and Anza has since moved npm write access to revocable, granular tokens.

At a glance

What happened

@solana/web3.js is the Solana JavaScript SDK that applications use to build transactions and manage keypairs. Socket put its use at about 350,000 weekly downloads, and The Register at almost half a million. Projects that track the latest tag, or rebuild with loose version ranges, pick up a new release automatically, so whoever controls publishing for the package can reach a large share of the ecosystem within hours.

Anza's root cause analysis says a spear phishing campaign targeted developers with publish rights in the @solana npm namespace on 3 December 2024. The emails appeared to come from a team member and invited the recipient to a private package. At 3:20pm UTC, one member with publish access followed the link to a clone of the npm website and entered their username, password and two-factor code. Moments later, versions 1.95.6 and 1.95.7 appeared on npm. Anza says the two were identical apart from the version number. The attacker had added code to new Account(), Keypair.fromSecretKey(), Keypair.fromSeed() and the Ed25519 and Secp256k1 instruction helpers, so any application that touched a private key through those functions could send it to the attacker.

Datadog researcher Christophe Tafani-Dereeper found that the backdoor "adds an 'addToQueue' function which exfiltrates the private key", as quoted by The Register. Socket reports that the key data was disguised as Cloudflare-style headers and sent to sol-rpc[.]xyz, a domain registered on 22 November. The compromise was spotted by an ecosystem team that had deployed a malicious version and saw unauthorised transfers from its own wallets to the attacker's address, according to Anza.

Once Anza began investigating, the clean-up took about an hour. An engineer began investigating at 7:27pm UTC, the account's npm credentials were revoked at 7:30pm, 1.95.5 was restored as latest at 7:39pm and a clean 1.95.8 was published at 8:25pm. npm staff removed the bad versions shortly after midnight, and the GitHub advisory (GHSA-jcxm-7wvp-g6p5) followed on the morning of 4 December. The advisory states that "a publish-access account was compromised for @solana/web3.js". Anza stressed that "The Solana protocol was not compromised by the web3.js exploit." Mumtaz told users that "In general, wallets should not be affected since they don't expose private keys."

Timeline

How it happened: the identity attack path

1. Target the publishers. The attacker identified people with publish rights in the @solana npm namespace and sent them emails posing as a colleague.
2. Phish the credentials and the code. A cloned npm site captured one member's username, password and two-factor code, which was everything npm needed to accept a publish.
3. Publish as the maintainer. The attacker pushed two releases under the trusted package name. Every automated build that pulled the latest version trusted them.
4. Hook the key functions. The injected code sat inside the functions that load and create keypairs, so it saw private keys at the moment applications used them.
5. Exfiltrate and drain. Keys went to the attacker's server, and funds were moved from affected wallets to an attacker-controlled address.

Impact

• Confirmed: private keys were stolen from applications that installed 1.95.6 or 1.95.7 during the five-hour window, and funds were drained, according to Anza and the GitHub advisory.
• Estimated losses: about $130,000 according to Mert Mumtaz of Helius Labs, and about $160,000 according to Decrypt, as reported by Socket. Anza did not give a total or the number of affected applications.
• Not affected: the Solana protocol and non-custodial wallets. Mumtaz said major wallets and apps such as Phantom, Backpack, Coinbase, Exodus and Kamino were not affected or did not use the compromised versions, as reported by Socket.
• Potential: any project that pinned or cached the bad versions, directly or as a transitive dependency, stayed exposed until it upgraded and rotated its keys.

What this means for NHI governance

A package publishing identity is a non-human identity in all but name. The person behind it is human, but what the registry trusts is a credential that signs code into thousands of build pipelines, with no human review between publish and install. In this case that credential was a username, a password and a one-time code, all of which can be typed into a fake site. Once the attacker had them, npm had no reason to doubt the release.

The second identity layer is the private keys the malware went after. Bots and backend services that keep signing keys in application memory are exactly where a poisoned SDK can see them. Phishing-resistant authentication for publishers, short-lived and granular publishing tokens, and keeping signing keys out of application code all reduce the blast radius. The same pattern hit Ledger a year earlier and LottieFiles a month earlier. See our CI/CD Pipeline Identity Security Guide and Cryptographic Key Management Guide.

Recommendations

• Use phishing-resistant authentication for publishers. Hardware security keys or passkeys stop a cloned login page from capturing a usable second factor. See our MFA Guide.
• Replace interactive publishing with scoped, short-lived tokens. Anza moved write access to revocable, granular tokens. Where the registry supports it, publish only from CI with trusted publishing and provenance. See our CI/CD Pipeline Identity Security Guide.
• Keep the publisher list short. Review who can publish each package and remove anyone who does not need it, as Anza did for its npm organisations.
• Keep signing keys out of application memory. Use hardware security modules, key management services or remote signers for bots and backend services. See our Cryptographic Key Management Guide.
• Pin dependencies and use lockfiles. Avoid floating latest tags in production builds, and delay adoption of brand-new releases where you can.
• Rotate keys after exposure. If 1.95.6 or 1.95.7 was ever installed, rotate authority keys, multisig signers, program authorities and server keypairs, as the advisory advises. See our Leaked Credential Response Playbook.

Frequently asked questions

Which versions of @solana/web3.js were malicious?

Versions 1.95.6 and 1.95.7, published on 3 December 2024 and available between 3:20pm and 8:25pm UTC. They have been removed from npm. Version 1.95.8 is clean, and anyone who installed the bad versions should rotate any private keys those applications handled.

How did attackers get access to publish @solana/web3.js?

According to Anza's root cause analysis, a member of the @solana npm organisation with publish rights received a spear phishing email, followed a link to a fake npm site and entered their username, password and two-factor code. The attacker used them to publish the two malicious releases.

Was the Solana blockchain hacked?

No. Anza says the Solana protocol was not compromised. The attack hit a JavaScript client library, and only applications that handle private keys directly, such as bots and backend services, were at risk. Non-custodial wallets should not have been affected.

Related NHI Mgmt Group resources

Ledger Connect Kit npm compromise 2023 · Lottie Player npm compromise 2024 · Rspack npm compromise 2024 · CI/CD Pipeline Identity Security Guide · Cryptographic Key Management Guide

How NHI Mgmt Group can help

Publishing identities and signing keys are some of the most powerful non-human identities in software delivery, and they are often protected like ordinary user accounts. We help teams inventory who can publish, move to short-lived and phishing-resistant credentials and keep keys out of application code. See our NHI and AI agent security training.

References

• Socket: Supply Chain Attack Detected in Solana's web3.js Library (3 December 2024)
• GitHub Security Advisory: Modified package published to npm, containing malware that exfiltrates private key material (4 December 2024)
• Anza: web3.js Exploit: Root Cause Analysis (5 December 2024)
• The Register: Solana JavaScript SDK backdoored to steal keys, funds (5 December 2024)