The @solana/web3.js Backdoor Explained

Video transcript

On December 3, 2024, one phished npm login let an attacker ship key-stealing versions of the Solana web3 JavaScript library.

A spear phishing email led one developer to a fake npm site. Their password and two-factor code were enough to publish two malicious versions.

The code sat where the library handles private keys. An added function, add to queue, sent them to an attacker domain inside seemingly legitimate Cloudflare headers.

The phish landed at 3:20 in the afternoon, UTC. About four hours later, a team saw unauthorized transfers and Anza began investigating.

Anza's analysis gives no loss figure. Published estimates range from roughly 130,000 to about 184,000 dollars.

No flaw in the Solana protocol was involved. The perimeter was one npm login. Anza now routes write access through revocable, granular tokens.

Exposure came down to timing and key handling. Projects like bots that updated during the window were at risk. Pinned versions stayed out, and non-custodial wallets should not have been affected.

Upgrading was not enough. Exposed teams should check dependencies, upgrade, then rotate suspect authority keys like multisigs and server keypairs.

Guardian's SDK Audit reviews what one bad release would do. Three of its areas match this incident: key handling, the published artifact and release control.

Read the full article, or talk to Guardian about reviewing your SDK before its next release.

@solana/web3.js is a widely used JavaScript library for Solana apps. Socket put its npm downloads at more than 350,000 a week.

On December 3, 2024, two versions of it carried a backdoor that sent private keys to an attacker. The advisory's exposure window lasted about five hours.

No flaw in the Solana protocol was involved. The attacker needed one developer's npm login.

What Happened

On December 3, developers with publish access to the @solana npm organization were targeted by spear phishing, Anza's root cause analysis says.

The emails invited them to collaborate on a private package. They appeared to come from another team member.

One developer clicked through to a clone of the npm website controlled by the attacker. There they entered their npm username and password and completed a round of two-factor authentication.

That was enough to publish two modified versions, 1.95.6 and 1.95.7, within moments. Anza says the two were identical apart from the version number.

GitHub's advisory tracks the incident as CVE-2024-54134, rated High with a CVSS 4.0 score of 8.3.

How the Backdoor Worked

The attacker put the malicious code where the library handles private keys. Anza lists five places:

• new Account()
• Keypair.fromSecretKey()
• Keypair.fromSeed()
• Ed25519Program.createInstructionWithPrivateKey()
• Secp256k1Program.createInstructionWithPrivateKey()

Datadog researcher Christophe Tafani-Dereeper found an added function, addToQueue. It sent keys out through "seemingly-legitimate CloudFlare headers," Socket and BleepingComputer reported.

The keys went to sol-rpc[.]xyz. Socket says the domain was registered on November 22 and sat behind Cloudflare.

Who was exposed

The advisory names projects that handle private keys directly, such as bots, and that updated during the window.

Non-custodial wallets should not be affected, "as they generally do not expose private keys during transactions," the advisory says.

Helius's Mert Mumtaz said Phantom, Backpack, Coinbase, Exodus and Kamino were not affected, Socket reported.

Timeline and Loss

Times are UTC, from Anza's root cause analysis.

Anza's analysis gives no loss figure. Published estimates differ:

• About $184,000, by Solscan's estimate, BleepingComputer reported on December 4.
• $164,100 (674.86 SOL), The Hacker News reported, citing Solscan and Solana Explorer.
• Roughly $130,000, by Mert Mumtaz's estimate, Socket reported.

What It Shows

One login was the perimeter. A password and a 2FA code, typed into a fake site, were enough to publish.

Anza then removed every user from its @solana and @solana-program npm organizations. Write access now runs through "revocable, granular access tokens."

The window decided exposure. Only key-handling projects that updated during those five hours appear affected, per the advisory.

A project on pinned versions, or one that waited before adopting new releases, stayed out of it. Our npm supply chain guide covers lockfiles, cooldowns and install controls.

Victims raised the alarm. Anza began investigating after an ecosystem team saw unauthorized transfers from its own wallets.

Key handling set the blast radius. Apps that pass raw secret keys through the library were exposed; non-custodial wallets should not have been.

Upgrading was not enough. The advisory tells exposed teams to rotate suspect authority keys, including multisigs, program authorities and server keypairs.

The pattern repeats: see the xrpl.js backdoor and the Ledger Connect Kit attack.

How SDK Audit Tests This

Guardian's SDK Audit reviews what a library does with a payload and "what one bad release would do," its service page says.

Three of its six areas match this incident:

• Key and credential handling: signers, seeds, tokens and API keys, how long they stay in memory, what leaks to logs.
• Published artifact: what ships to the registry versus the repo, including install scripts and dependencies.
• Release control: who can publish, whether 2FA and provenance are enforced, how a bad version gets pulled.

Guardian reviews both the source and the published package. Its page says "the gap between them is where supply-chain risk lives."

The audit covers TypeScript, Python, Rust, Go and JVM client libraries for EVM and Solana. It is scoped by the public surface and the release pipeline.

After release, Managed Security matches new vulnerability disclosures against what you run. Where one reaches you, an engineer confirms the exposure and works with you on the patch.

For the wider offchain scope, read web3 penetration testing explained.

Frequently Asked Questions

Which @solana/web3.js versions were malicious?

Versions 1.95.6 and 1.95.7, published on December 3, 2024 and later removed from npm. Version 1.95.8 is the clean release. The incident is tracked as CVE-2024-54134 and GHSA-jcxm-7wvp-g6p5.

Were Phantom and other wallets affected?

The advisory says non-custodial wallets should not be affected, as they generally do not expose private keys during transactions. Helius's Mert Mumtaz said major wallets and apps, including Phantom and Backpack, were not affected, Socket reported.

What should a team do if it installed a bad version?

Check direct and transitive dependencies for 1.95.6 or 1.95.7 and upgrade. Then rotate any suspect authority keys: the advisory names multisigs, program authorities and server keypairs. BleepingComputer adds: move remaining funds to a new wallet.

How much was stolen?

Estimates vary. BleepingComputer cited a Solscan estimate of about $184,000, and The Hacker News reported $164,100 (674.86 SOL). Anza's root cause analysis gives no figure.

Sources

• GitHub Advisory Database: Modified package published to npm, containing malware that exfiltrates private key material, GHSA-jcxm-7wvp-g6p5 (December 4, 2024)
• NIST NVD: CVE-2024-54134 (December 4, 2024)
• Anza: web3.js Exploit, Root Cause Analysis (December 5, 2024)
• BleepingComputer: Solana Web3.js library backdoored to steal secret, private keys (December 4, 2024)
• Socket: Supply Chain Attack Detected in Solana's web3.js Library (December 3, 2024, updated December 4)
• The Hacker News: Researchers Uncover Backdoor in Solana's Popular Web3.js npm Library (December 4, 2024)
• Guardian: SDK Security Audit for EVM and Solana