@solana/web3.js Private Key Exfiltration (2024)

Summary

On December 2–3, 2024, attackers compromised publish credentials for the official @solana/web3.js JavaScript SDK and shipped two malicious versions — 1.95.6 and 1.95.7 — containing code that exfiltrated private keys from any application that initialized a Keypair while running the affected versions. The package is the canonical client library for the Solana blockchain and is consumed by wallets, exchanges, dApps, and bots across the ecosystem. The compromise window was approximately five hours.

Timeline

• 2024-12-02 ~15:20 UTC — Malicious @solana/web3.js@1.95.6 published.
• 2024-12-02 ~17:01 UTC — 1.95.7 published.
• 2024-12-02 evening — Anomalous private key activity reported by downstream consumers via Solana developer forums.
• 2024-12-03 ~early UTC — Both versions removed by npm; clean 1.95.8 published.
• 2024-12-03 — Anza (the development collective maintaining the SDK) publishes the official advisory.

Attack Vector

The compromise was credential-based — the publish credentials of a @solana/web3.js maintainer were obtained, with the public advisory describing the credentials as having been phished. The technical payload chain:

1. Attacker logs into the npm account using stolen credentials.
2. Attacker publishes patch versions injecting a small, well-targeted code block into the SDK.
3. The injected code modifies the Keypair initialization path so that whenever a private key is created or loaded, the key is also POSTed to an attacker-controlled exfiltration endpoint.
4. The endpoint quietly collected keys for hours before defender attention triggered the takedown.

The attack is unusually surgical compared to the broad credential-vacuums of ua-parser-js or the Shai-Hulud campaign. The payload targets exactly one credential type — Solana private keys — because the package is exactly the right surface for that target.

Tokens & Credentials Exposed

• Solana private keys initialized or loaded by any application running the affected SDK versions.
• For wallet applications, this includes user wallet keys.
• For backend services, this includes hot-wallet keys, signer keys, and program upgrade authority keys.
• For automated bots (arbitrage, MEV, oracle nodes), this includes the operational keys controlling on-chain assets and authority.

A Solana private key is structurally a signing key with full authority over whatever assets and programs it controls. There is no "read-only" mode; a captured key is an actionable credential the moment it lands at the attacker.

Confirmed Impact

• Approximately $160,000+ in initial confirmed thefts in the immediate aftermath (numbers continued to grow as affected applications discovered drained accounts post-disclosure).
• Multiple bot operators and small-scale dApps confirmed key exfiltration and asset loss. Larger exchanges generally use HSM-backed signing for hot wallets and were not directly affected.
• Wallet vendors that bundle @solana/web3.js audited their releases for the affected window. Several published advisories asking users to confirm whether they had updated to the affected versions during the exposure window.

The structural impact is larger than the immediate financial loss: the incident demonstrated that targeting a domain-specific SDK is a viable attack pattern when the credential type is high-value enough to justify the precision.

Mitigation & Lessons

If you operate any application using @solana/web3.js:

• Confirm your installed version was not 1.95.6 or 1.95.7 during the exposure window. If it was, treat every Solana private key the application initialized in that window as compromised.
• Rotate exposed keys immediately by transferring assets to a new keypair and updating any program authority assignments.
• Audit lockfile pinning practices. Projects that pinned @solana/web3.js to a specific patch version were unaffected. Projects that allowed automatic patch upgrades during the window were the primary exposure surface.

Wider lessons:

• Domain-specific SDKs are high-value supply chain targets. A package that is consumed only by Solana developers is a small fraction of the npm ecosystem by download count, but every install hits a wallet of some kind. Blast radius is not a function of download count alone — it is a function of what the install reaches.
• Lockfile pinning and provenance attestations are now baseline expectations for cryptocurrency-handling applications.
• MFA enforcement on maintainer accounts for high-blast-radius packages is the single most effective control. The 2024 incident happened despite npm's general MFA push — phishing remains the dominant bypass vector.

Cremit Analysis

This is ghost-key with a sharper edge than the broader npm credential incidents.

Ghost Key: the maintainer's npm credential is the only identity gating publish access to a package controlling a substantial fraction of the Solana ecosystem's client-side cryptography. There is no operational signal that distinguishes a legitimate publish from an attacker's publish other than the credential itself.

Drifted Key: @solana/web3.js was originally a developer-experience SDK; by 2024 it had drifted into the dependency tree of consumer wallets, automated trading systems, and on-chain infrastructure controlling material funds. The trust posture appropriate for a developer SDK is wildly inappropriate for a package that handles signing material in production.

The NHI Severity Index score of 8.4 reflects ecosystem-wide reach within the Solana ecosystem (the SDK is the canonical library), production reachability (every install touches active signing keys), and admin-level privilege (a captured private key has full authority over the assets it controls). The score is slightly below ua-parser-js because the blast radius is bounded to one ecosystem rather than the entire JavaScript world — but the per-credential value is substantially higher.

The generalizable lesson: the attack surface is not where the value is stored, it is where the value moves. Solana wallets store private keys in hardware enclaves, encrypted local storage, or HSMs. The keys move through @solana/web3.js every time they are used. Attacking the path of motion is structurally easier than attacking the storage. This is the same pattern Shai-Hulud applied to CI runner credentials in 2025–2026.