Web3 & Crypto Wallet Developer Security in 2026: When Your npm Dependency Steals Private KeysSécurité Web3 & Wallets Crypto pour Développeurs en 2026 : Quand Votre Dépendance npm Vole Vos Clés Privées

Two npm supply chain attacks hit the crypto world in the span of four days in July 2026. On July 8, a compromised GitHub account silently hooked the Injective SDK's key-derivation functions, exfiltrating BIP-39 seed phrases from 175,000 monthly downloads across 18 republished packages. Three days later, on July 11, jscrambler — a commercial JavaScript security tool — was trojaned with a 7.8 MB Rust infostealer that targeted AWS, Azure, GCP, Bitwarden, and the config files of Claude Desktop and Cursor. A headline from Startup Fortune summed it up bluntly: "Two npm attacks in four days show crypto's weak point is the supply chain."

Deux attaques supply chain npm ont frappé le monde crypto en l'espace de quatre jours en juillet 2026. Le 8 juillet, un compte GitHub compromis a silencieusement hooké les fonctions de dérivation de clés de l'Injective SDK, exfiltrant des seed phrases BIP-39 depuis 175 000 téléchargements mensuels via 18 packages republiés. Trois jours plus tard, le 11 juillet, jscrambler — outil commercial de sécurité JavaScript — a été troyanisé avec un infostealer Rust de 7,8 Mo ciblant AWS, Azure, GCP, Bitwarden et les fichiers de config de Claude Desktop et Cursor. Un titre de Startup Fortune l'a résumé sans détour : « Deux attaques npm en quatre jours montrent que le maillon faible de la crypto, c'est la supply chain. »

These attacks are not anomalies. They are the new normal for anyone building Web3 applications with npm dependencies. Supply chain attacks have officially overtaken smart contract exploits as the most devastating attack vector in the crypto ecosystem. The Bybit hack in February 2025 — $1.46 billion stolen through a compromised UI library — made this shift impossible to ignore. This guide explains how these attacks work at the technical level, what North Korean state actors specifically target on your development machine, and how to architect Web3 applications so that a compromised npm dependency cannot steal cryptographic keys — no matter what it tries.

Ces attaques ne sont pas des anomalies. Elles constituent la nouvelle norme pour quiconque construit des applications Web3 avec des dépendances npm. Les attaques supply chain ont officiellement dépassé les exploits de smart contracts comme vecteur d'attaque le plus dévastateur dans l'écosystème crypto. Le hack Bybit en février 2025 — 1,46 milliard de dollars volés via une bibliothèque UI compromise — a rendu ce changement impossible à ignorer. Ce guide explique comment ces attaques fonctionnent au niveau technique, ce que les acteurs étatiques nord-coréens ciblent spécifiquement sur votre machine de développement, et comment architecturer les applications Web3 de sorte qu'une dépendance npm compromise ne puisse pas voler des clés cryptographiques — quoi qu'elle tente.

The Bybit Precedent: How $1.46 Billion Was Stolen Through a JavaScript Library

Le Précédent Bybit : Comment 1,46 Milliard de Dollars ont été Volés via une Bibliothèque JavaScript

On February 21, 2025, attackers executed the largest cryptocurrency theft ever recorded. Bybit lost more than $1.46 billion — over 401,000 ETH — from a cold wallet. The attack did not exploit any vulnerability in the Ethereum protocol, any smart contract flaw, or any weakness in Bybit's own code. It exploited a UI library.

Le 21 février 2025, des attaquants ont réalisé le plus grand vol de cryptomonnaies jamais enregistré. Bybit a perdu plus de 1,46 milliard de dollars — plus de 401 000 ETH — depuis un portefeuille froid. L'attaque n'a exploité aucune vulnérabilité dans le protocole Ethereum, aucune faille de smart contract, ni aucune faiblesse dans le propre code de Bybit. Elle a exploité une bibliothèque UI.

The target was Safe{Wallet}, a widely-used multi-signature wallet solution. Attackers social-engineered a Safe{Wallet} developer, compromised their workstation, and used stolen AWS credentials to access the S3 bucket that hosted the wallet's frontend JavaScript. The injected code then manipulated what Bybit's signers saw on their screens during a routine transfer, causing them to unknowingly approve a transaction that drained the wallet to attacker-controlled addresses. Everything looked legitimate because the compromise happened at the UI layer — the layer that npm dependencies directly control.

La cible était Safe{Wallet}, une solution de portefeuille multi-signature largement utilisée. Les attaquants ont usé d'ingénierie sociale contre un développeur Safe{Wallet}, compromis sa machine, et utilisé des identifiants AWS volés pour accéder au bucket S3 hébergeant le JavaScript frontend du portefeuille. Le code injecté a ensuite manipulé ce que les signataires de Bybit voyaient à l'écran lors d'un transfert de routine, les amenant à approuver inconsciemment une transaction qui a vidé le portefeuille vers des adresses contrôlées par l'attaquant. Tout semblait légitime car la compromission s'est produite au niveau de la couche UI — la couche que les dépendances npm contrôlent directement.

The lesson for Web3 developers is not "use a better wallet UI." The lesson is that any dependency with access to the DOM, to transaction-signing APIs, or to the process memory where private keys reside is a potential attack vector — and the attacker does not need to exploit your code at all.

La leçon pour les développeurs Web3 n'est pas « utilisez une meilleure interface de portefeuille ». La leçon est que toute dépendance ayant accès au DOM, aux API de signature de transactions, ou à la mémoire de processus où résident les clés privées, est un vecteur d'attaque potentiel — et l'attaquant n'a pas besoin d'exploiter votre propre code.

Shai-Hulud: When chalk and debug Became Crypto Drainers (September 2025)

Shai-Hulud : Quand chalk et debug Sont Devenus des Crypto Drainers (Septembre 2025)

On September 8, 2025, npm's first genuinely self-propagating malware turned 18 popular packages — including chalk and debug — into cryptocurrency drainers. Sonatype and Socket identified close to 500 impacted packages by September 16, with combined weekly downloads exceeding 2.6 billion. The initial vector was a phishing email that mimicked an npm account recovery notification, sent from a fake domain (npmjs.help). The attacker collected the maintainer's username, password, and a live TOTP code, then published malicious versions within 16 minutes of gaining access.

Le 8 septembre 2025, le premier malware véritablement auto-propagant de npm a transformé 18 packages populaires — dont chalk et debug — en draineurs de cryptomonnaies. Sonatype et Socket ont identifié près de 500 packages impactés au 16 septembre, avec des téléchargements hebdomadaires cumulatifs dépassant 2,6 milliards. Le vecteur initial était un email de phishing imitant une notification de récupération de compte npm, envoyé depuis un faux domaine (npmjs.help). L'attaquant a collecté le nom d'utilisateur, le mot de passe et un code TOTP en direct du mainteneur, puis publié des versions malveillantes dans les 16 minutes suivant l'obtention de l'accès.

The malicious code executed in browser environments with surgical precision. It hooked into window.ethereum — the Web3 provider injected by MetaMask and most other browser wallets — to intercept outgoing transaction calls. When a user initiated a transaction, the code silently replaced the recipient address with an attacker-controlled address, using a Levenshtein nearest-match algorithm to substitute visually similar addresses that would pass a casual glance. It also overrode fetch and XMLHttpRequest to scan API responses for blockchain addresses, then replaced them on the fly. The malicious versions stayed live for two hours — but in npm terms, two hours is enough to poison millions of node_modules directories.

Le code malveillant s'exécutait dans les environnements navigateur avec une précision chirurgicale. Il s'accrochait à window.ethereum — le fournisseur Web3 injecté par MetaMask et la plupart des autres portefeuilles navigateur — pour intercepter les appels de transactions sortantes. Lorsqu'un utilisateur initiait une transaction, le code remplaçait silencieusement l'adresse du destinataire par une adresse contrôlée par l'attaquant, en utilisant un algorithme de distance de Levenshtein pour substituer des adresses visuellement similaires passant inaperçues au premier coup d'œil. Il surchargeait également fetch et XMLHttpRequest pour analyser les réponses API à la recherche d'adresses blockchain, puis les remplaçait à la volée. Les versions malveillantes sont restées en ligne deux heures — mais en termes npm, deux heures suffisent à empoisonner des millions de répertoires node_modules.

The Shai-Hulud worm's self-propagation mechanism was what made it historically significant: once installed, it searched the local npm registry configuration and published malicious versions of other packages the same account had access to, spreading without any further action from the attacker. This is the characteristic that separates the 2025-2026 threat landscape from everything that came before.

Le mécanisme d'auto-propagation du ver Shai-Hulud est ce qui l'a rendu historiquement significatif : une fois installé, il recherchait la configuration du registre npm local et publiait des versions malveillantes des autres packages auxquels le même compte avait accès, se propageant sans aucune action supplémentaire de l'attaquant. C'est cette caractéristique qui distingue le paysage des menaces 2025-2026 de tout ce qui précèdait.

Injective July 2026: Hooking Key-Derivation Functions via Fake Telemetry

Injective Juillet 2026 : Hook des Fonctions de Dérivation de Clés via Fausse Télémétrie

The July 8, 2026 Injective attack introduced a pattern that security researchers at Datadog Security Labs called "telemetry camouflage." An attacker used a compromised GitHub account to introduce a fake key-derivation timing measurement module into the @injectivelabs/sdk-ts package. The module was structured to look like a legitimate performance telemetry system — measuring how long key operations took to complete.

L'attaque Injective du 8 juillet 2026 a introduit un pattern que les chercheurs en sécurité de Datadog Security Labs ont appelé « camouflage de télémétrie ». Un attaquant a utilisé un compte GitHub compromis pour introduire un faux module de mesure de performance de dérivation de clés dans le package @injectivelabs/sdk-ts. Le module était structuré pour ressembler à un système légitime de télémétrie de performance — mesurant la durée des opérations de clé.

In practice, it hooked two methods: PrivateKey.fromMnemonic() and PrivateKey.fromHex(). Every time a wallet was created or a key was loaded from a BIP-39 mnemonic phrase, the hook fired — capturing the raw mnemonic and encoding it in Base64 inside a custom HTTP header, X-Request-Id, sent to a server disguised as Injective's own testnet archival infrastructure. The choice of header was deliberate: X-Request-Id appears in legitimate API traffic and passes most WAF and firewall rules without inspection.

En pratique, il hookait deux méthodes : PrivateKey.fromMnemonic() et PrivateKey.fromHex(). Chaque fois qu'un portefeuille était créé ou qu'une clé était chargée depuis une phrase mnémonique BIP-39, le hook se déclenchait — capturant le mnémonique brut et l'encodant en Base64 dans un header HTTP personnalisé, X-Request-Id, envoyé à un serveur déguisé en infrastructure archivale de testnet Injective. Le choix du header était délibéré : X-Request-Id apparaît dans le trafic API légitime et passe la plupart des règles WAF et pare-feu sans inspection.

GitHub Actions then automatically republished 18 packages in the @injectivelabs scope in 82 seconds — all bearing the malicious dependency. The versions stayed live for 49 minutes before detection. The same week, 17 additional fake payment SDKs mimicking Paysafe, Skrill, and Neteller appeared on npm and PyPI, stealing PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, and GITHUB_TOKEN environment variables from any CI/CD pipeline that installed them. These two campaigns — running simultaneously — show how state-sponsored actors now operate: multiple attack vectors, synchronized deployment, and precision targeting of specific developer ecosystems.

GitHub Actions a ensuite automatiquement republié 18 packages du scope @injectivelabs en 82 secondes — tous portant la dépendance malveillante. Les versions sont restées en ligne 49 minutes avant détection. La même semaine, 17 faux SDKs de paiement imitant Paysafe, Skrill et Neteller sont apparus sur npm et PyPI, volant les variables d'environnement PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY et GITHUB_TOKEN depuis tout pipeline CI/CD les ayant installés. Ces deux campagnes — menées simultanément — montrent comment les acteurs étatiques opèrent désormais : multiples vecteurs d'attaque, déploiement synchronisé et ciblage précis d'écosystèmes de développeurs spécifiques.

What DPRK Specifically Targets on a Web3 Developer's Machine

Ce que la Corée du Nord Cible Spécifiquement sur la Machine d'un Développeur Web3

North Korean state actors — operating under the Lazarus Group umbrella and tracked by SecurityScorecard STRIKE as the Contagious Interview cluster — are responsible for 76% of all crypto hack losses in the first half of 2026, totaling approximately $577 million of $759 million stolen across the entire crypto industry. Their npm-based campaigns are not generic infostealers. They are precision tools built to harvest the specific credentials that let an attacker move laterally from a developer's machine to production infrastructure and live wallets.

Les acteurs étatiques nord-coréens — opérant sous l'ombrelle du Lazarus Group et suivis par SecurityScorecard STRIKE comme le cluster Contagious Interview — sont responsables de 76% de toutes les pertes crypto au premier semestre 2026, représentant environ 577 millions des 759 millions de dollars volés dans l'ensemble de l'industrie crypto. Leurs campagnes basées sur npm ne sont pas des infostealers génériques. Ce sont des outils de précision conçus pour récolter les identifiants spécifiques permettant à un attaquant de se déplacer latéralement depuis la machine d'un développeur vers l'infrastructure de production et les portefeuilles actifs.

Analysis of the Lazarus rollup polyfill campaign (JFrog, July 2026), the Miasma Phantom Gyp campaigns (Wiz, Microsoft, Snyk, June 2026), and the jscrambler attack (Socket, July 2026) reveals a consistent targeting pattern. The payloads methodically search for:

L'analyse de la campagne Lazarus rollup polyfill (JFrog, juillet 2026), des campagnes Miasma Phantom Gyp (Wiz, Microsoft, Snyk, juin 2026) et de l'attaque jscrambler (Socket, juillet 2026) révèle un pattern de ciblage cohérent. Les payloads recherchent méthodiquement :

• Foundry wallets: ~/.foundry/keystores/, ~/.foundry/accounts/ — the development wallets used by Solidity developers for local testing, often funded with real assets for staging environments.
• Portefeuilles Foundry : ~/.foundry/keystores/, ~/.foundry/accounts/ — les portefeuilles de développement utilisés par les développeurs Solidity pour les tests locaux, souvent alimentés avec de vrais actifs pour les environnements de staging.
• AI coding tool credentials: ~/.config/claude/, ~/.cursor/, ~/.gemini/ — session tokens that can be used to exfiltrate proprietary code, discover other secrets in context windows, and poison coding agent instructions via .cursorrules or .claude/settings.json.
• Identifiants des outils IA : ~/.config/claude/, ~/.cursor/, ~/.gemini/ — tokens de session pouvant servir à exfiltrer du code propriétaire, découvrir d'autres secrets dans les fenêtres de contexte, et empoisonner les instructions des agents de codage via .cursorrules ou .claude/settings.json.
• Cloud credentials: ~/.aws/credentials, ~/.azure/, ~/.config/gcloud/ — direct access to cloud infrastructure where hot wallets, signing services, and key vaults are deployed.
• Identifiants cloud : ~/.aws/credentials, ~/.azure/, ~/.config/gcloud/ — accès direct à l'infrastructure cloud où sont déployés les portefeuilles chauds, services de signature et coffres de clés.
• SSH keys and GitHub tokens: ~/.ssh/, ~/.gitconfig, stored GitHub CLI tokens — to enable further supply chain compromise by pushing to downstream repositories with legitimate-looking commits.
• Clés SSH et tokens GitHub : ~/.ssh/, ~/.gitconfig, tokens GitHub CLI stockés — pour permettre une compromission supply chain en aval en poussant vers des dépôts avec des commits d'apparence légitime.
• npm and package manager tokens: ~/.npmrc (_authToken), ~/.yarnrc.yml — publishing credentials that turn the compromised developer into an involuntary supply chain attack vector against their own packages.
• Tokens npm et gestionnaire de packages : ~/.npmrc (_authToken), ~/.yarnrc.yml — identifiants de publication qui font du développeur compromis un vecteur involontaire d'attaque supply chain contre ses propres packages.
• Clipboard and IDE history: The Lazarus RAT (July 2026 rollup campaign) added continuous clipboard monitoring to capture private keys and seed phrases copied during development workflows.
• Presse-papiers et historique IDE : Le RAT Lazarus (campagne rollup de juillet 2026) a ajouté une surveillance continue du presse-papiers pour capturer les clés privées et seed phrases copiées pendant les workflows de développement.

The exfiltration channels have also evolved. Early campaigns used straightforward HTTPS POST requests. Recent campaigns use DNS TXT queries (node-ipc, May 2026), HTTP header smuggling (Injective, July 2026), and even blockchain RPC calls to TRON and Aptos networks as C2 channels (PolinRider, July 2026) — all to bypass network monitoring tools that only inspect conventional HTTP traffic.

Les canaux d'exfiltration ont également évolué. Les premières campagnes utilisaient des requêtes HTTPS POST directes. Les campagnes récentes utilisent des requêtes DNS TXT (node-ipc, mai 2026), la contrebande de headers HTTP (Injective, juillet 2026), et même des appels RPC blockchain vers les réseaux TRON et Aptos comme canaux C2 (PolinRider, juillet 2026) — tout cela pour contourner les outils de surveillance réseau qui n'inspectent que le trafic HTTP conventionnel.

Key Isolation: Building Web3 Apps That Can't Leak Private Keys

Isolation des Clés : Construire des Apps Web3 qui ne Peuvent pas Fuiter de Clés Privées

The fundamental security principle violated in every Web3 supply chain attack is key isolation: the private key must never share a process, a memory space, or a filesystem path with any untrusted dependency. Most Web3 applications violate this principle by default. They load a private key from an environment variable or a keystore file into the same Node.js process that also runs dozens of npm dependencies — any one of which could be compromised at any moment.

Le principe de sécurité fondamental violé dans chaque attaque supply chain Web3 est l'isolation des clés : la clé privée ne doit jamais partager un processus, un espace mémoire ou un chemin de système de fichiers avec une dépendance non approuvée. La plupart des applications Web3 violent ce principe par défaut. Elles chargent une clé privée depuis une variable d'environnement ou un fichier keystore dans le même processus Node.js qui exécute également des dizaines de dépendances npm — dont n'importe laquelle pourrait ême compromise à tout moment.

Architecture Pattern: The Signing Service

Pattern d'Architecture : Le Service de Signature

The recommended architecture for production Web3 applications separates key operations into a dedicated signing service with a minimal, pinned dependency tree. The main application — which handles business logic, user interactions, and npm dependencies from the broader ecosystem — never touches private keys. It sends unsigned transaction data to the signing service and receives a signed transaction in return. The signing service runs in a separate process (or separate container), has no public-facing network interface, and communicates only via a local IPC socket or an authenticated internal API.

L'architecture recommandée pour les applications Web3 en production sépare les opérations de clé dans un service de signature dédié avec un arbre de dépendances minimal et pinned. L'application principale — qui gère la logique métier, les interactions utilisateur et les dépendances npm de l'écosystème plus large — ne touche jamais les clés privées. Elle envoie des données de transaction non signées au service de signature et reçoit une transaction signée en retour. Le service de signature s'exécute dans un processus séparé (ou un conteneur séparé), n'a pas d'interface réseau publique et communique uniquement via un socket IPC local ou une API interne authentifiée.

┌─────────────────────────────────────────────────────────────────┐
│  Application Process (many npm deps, full ecosystem exposure)   │
│  ┌──────────────┐     unsigned tx      ┌──────────────────────┐ │
│  │  Business    │ ─────────────────── ▶│  Signing Service     │ │
│  │  Logic       │ ◀─────────────────── │  (3 pinned deps max) │ │
│  └──────────────┘     signed tx        │  Private key: HSM /  │ │
│                                        │  AWS KMS / Vault     │ │
│                                        └──────────────────────┘ │
│  KEY RULE: private key never crosses this boundary              │
└─────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│  Processus Application (nombreuses deps npm, exposition totale)  │
│  ┌──────────────┐   tx non signée    ┌──────────────────────┐   │
│  │  Logique     │ ─────────────────── ▶│  Service de Signature│   │
│  │  Métier      │ ◀─────────────────── │  (3 deps pinées max) │   │
│  └──────────────┘   tx signée         │  Clé privée : HSM /  │   │
│                                         │  AWS KMS / Vault     │   │
│                                         └──────────────────────┘   │
│  RÈGLE ABSOLUE : la clé privée ne franchit jamais cette limite │
└──────────────────────────────────────────────────────────────────┘

Key Storage Options by Risk Level

Options de Stockage des Clés par Niveau de Risque

For production environments handling real funds, the signing service should delegate key storage to a dedicated system:

Pour les environnements de production manipulant de vrais fonds, le service de signature doit déléguer le stockage des clés à un système dédié :

• HSM (Hardware Security Module): Physical or cloud-attached device (e.g., AWS CloudHSM, Azure Dedicated HSM) where the private key never leaves the hardware in plaintext. Operations are performed inside the HSM. Highest security, highest operational complexity.
• HSM (Module de Sécurité Matérielle) : Dispositif physique ou attaché au cloud (ex. AWS CloudHSM, Azure Dedicated HSM) où la clé privée ne quitte jamais le matériel en clair. Les opérations sont exécutées dans le HSM. Sécurité maximale, complexité opérationnelle maximale.
• Cloud KMS (AWS KMS / Azure Key Vault / GCP KMS): Managed key management with signing APIs. The private key is stored in FIPS 140-2 validated hardware managed by the cloud provider. Practical for most Web3 backends. Signing calls are logged, auditable, and can be locked down to specific IAM roles.
• Cloud KMS (AWS KMS / Azure Key Vault / GCP KMS) : Gestion de clés administrée avec API de signature. La clé privée est stockée dans du matériel validé FIPS 140-2 géré par le fournisseur cloud. Pratique pour la plupart des backends Web3. Les appels de signature sont enregistrés, auditables et peuvent être restreints à des rôles IAM spécifiques.
• HashiCorp Vault: Self-hosted secrets manager with a Transit engine for cryptographic operations. The key never leaves Vault; your application sends data to sign and receives the signature. Good for teams that need portability across cloud providers.
• HashiCorp Vault : Gestionnaire de secrets auto-hébergé avec un moteur Transit pour les opérations cryptographiques. La clé ne quitte jamais Vault ; votre application envoie des données à signer et reçoit la signature. Bien adapté aux équipes ayant besoin de portabilité entre fournisseurs cloud.
• MPC Wallets (Multi-Party Computation): No single private key ever exists. The key is distributed across multiple parties; a signing quorum is required. Eliminates single-point-of-failure. Used by institutional custodians.
• Wallets MPC (Multi-Party Computation) : Aucune clé privée unique n'existe jamais. La clé est distribuée entre plusieurs parties ; un quorum de signature est requis. Élimine le point de défaillance unique. Utilisé par les dépositaires institutionnels.

CI/CD & Development Hardening for Web3 Teams

Durcissement CI/CD & Développement pour les Équipes Web3

Key isolation solves the production problem. Development environments are the other half of the attack surface — and the Injective, jscrambler, and Lazarus campaigns all explicitly targeted developer machines. The following measures reduce the blast radius of a compromised dependency in a development context:

L'isolation des clés résout le problème de production. Les environnements de développement constituent l'autre moitié de la surface d'attaque — et les campagnes Injective, jscrambler et Lazarus ont toutes explicitement ciblé les machines des développeurs. Les mesures suivantes réduisent le rayon d'explosion d'une dépendance compromise dans un contexte de développement :

• npm v12 (available July 2026): Install scripts (preinstall, postinstall) are blocked by default. Build your allowlist with npm approve-scripts and commit it to your repository. Note: Phantom Gyp (157-byte binding.gyp) and import-time execution (jscrambler 8.18.0+) bypass this — runtime monitoring is still required.
• npm v12 (disponible juillet 2026) : Les scripts d'installation (preinstall, postinstall) sont bloqués par défaut. Construisez votre allowlist avec npm approve-scripts et commitez-la dans votre dépôt. Note : Phantom Gyp (157 octets binding.gyp) et l'exécution à l'import (jscrambler 8.18.0+) contournent ceci — un monitoring d'exécution reste nécessaire.
• Pin exact versions, not semver ranges: For security-critical dependencies (SDK packages, cryptography libraries, wallet integrations), use exact version pins in your lockfile and enforce them with npm ci. A compromised patch version — e.g., 1.20.21 when you specified ^1.0.0 — will be installed automatically without your knowledge under semver.
• Pinner les versions exactes, pas les plages semver : Pour les dépendances critiques pour la sécurité (packages SDK, bibliothèques de cryptographie, intégrations wallet), utilisez des pins de version exacte dans votre lockfile et appliquez-les avec npm ci. Une version patch compromise — ex. 1.20.21 quand vous avez spécifié ^1.0.0 — sera installée automatiquement sans votre connaissance sous semver.
• Use devcontainers for development: Run your development environment inside a container that has no access to ~/.aws, ~/.foundry, ~/.ssh, or ~/.npmrc on the host. A compromised package inside a devcontainer cannot reach your host credentials.
• Utiliser des devcontainers pour le développement : Exécutez votre environnement de développement dans un conteneur sans accès à ~/.aws, ~/.foundry, ~/.ssh ou ~/.npmrc sur l'hôte. Un package compromis dans un devcontainer ne peut pas atteindre vos identifiants hôte.
• Egress allowlisting in CI/CD: Block all outbound network access from build machines except to known package registries. DNS TXT queries from a build machine are almost never legitimate. A compromised dependency that tries to exfiltrate via DNS TXT (node-ipc pattern) or blockchain RPC (PolinRider pattern) will silently fail without network access.
• Allowlist d'égress en CI/CD : Bloquez tout accès réseau sortant depuis les machines de build, sauf vers les registres de packages connus. Les requêtes DNS TXT depuis une machine de build sont presque jamais légitimes. Une dépendance compromise tentant d'exfiltrer via DNS TXT (pattern node-ipc) ou RPC blockchain (pattern PolinRider) échouera silencieusement sans accès réseau.
• Socket.dev integration: Socket monitors your dependency tree in real-time and flags packages that make outbound network calls, read environment variables, or contain obfuscated code. The jscrambler compromise was detected by Socket in 6 minutes. Add Socket to your CI/CD pipeline as a pre-install gate.
• Intégration Socket.dev : Socket surveille votre arbre de dépendances en temps réel et signale les packages effectuant des appels réseau sortants, lisant des variables d'environnement ou contenant du code obscurci. La compromission jscrambler a été détectée par Socket en 6 minutes. Ajoutez Socket à votre pipeline CI/CD comme gate pré-installation.
• Never store private keys in environment variables: process.env.PRIVATE_KEY is readable by every npm dependency in your process. Use AWS KMS, Vault, or a dedicated signing process instead. If you must use environment variables for development, ensure they contain only testnet keys funded with worthless test tokens.
• Ne jamais stocker les clés privées dans des variables d'environnement : process.env.PRIVATE_KEY est lisible par chaque dépendance npm dans votre processus. Utilisez AWS KMS, Vault ou un processus de signature dédié à la place. Si vous devez utiliser des variables d'environnement pour le développement, assurez-vous qu'elles ne contiennent que des clés de testnet alimentées avec des tokens de test sans valeur.
• Enable npm provenance attestations on your published packages: If your Web3 project publishes npm packages, use npm publish --provenance with GitHub Actions OIDC. Consumers can verify that what they installed matches your exact source commit. This is what TanStack's forged SLSA provenance exposed as insufficient — but L3 attestations combined with Sigstore verification significantly raise the bar.
• Activer les attestations de provenance npm sur vos packages publiés : Si votre projet Web3 publie des packages npm, utilisez npm publish --provenance avec GitHub Actions OIDC. Les consommateurs peuvent vérifier que ce qu'ils ont installé correspond à votre commit source exact. C'est ce que la provenance SLSA forgée de TanStack a exposé comme insuffisant — mais les attestations L3 combinées avec la vérification Sigstore relèvent significativement la barre.

Immediate Response: Were You Affected?

Réponse Immédiate : Êtes-vous Impacté ?

If your project installed any of the following packages during their compromise windows, rotate all credentials immediately — do not wait for further analysis:

Si votre projet a installé l'un des packages suivants pendant leurs fenêtres de compromission, faites pivoter tous les identifiants immédiatement — n'attendez pas d'analyse supplémentaire :

After rotating credentials, audit your lockfile diff to identify the exact version installed. Use npm ls --all | grep <package> to check for transitive dependencies that may have pulled in affected versions indirectly.

Après avoir fait pivoter les identifiants, auditez le diff de votre lockfile pour identifier la version exacte installée. Utilisez npm ls --all | grep <package> pour vérifier les dépendances transitives qui auraient pu tirer des versions impactées indirectement.

Frequently Asked Questions

Questions fréquentes