Attaque zero-day crypto 2026 : quand l’infrastructure devient le maillon faible
En 2026, les attaques zero-day contre l’écosystème crypto ont pris une ampleur inquiétante. Contrairement aux vulnérabilités connues et corrigées, les zero-days exploitent des failles inconnues des développeurs, offrant aux attaquants une fenêtre d’opportunité critique. Cette année est marquée par une évolution majeure : les hackers ciblent désormais prioritairement les infrastructures hors chaîne (SDK, bibliothèques, ponts, nœuds) plutôt que le code des smart contracts eux-mêmes.
Cet article analyse les principales attaques zero-day de 2026, leurs mécanismes et les leçons à en tirer pour sécuriser l’écosystème.
1. L’affaire node-forge : deux failles cryptographiques majeures (CVE-2026-33894 et CVE-2026-33895)
1.1. Une bibliothèque JavaScript largement utilisée
En juillet 2026, le CERT/CC a publié un avis critique concernant node-forge, une bibliothèque JavaScript largement utilisée pour les opérations cryptographiques dans Node.js et les navigateurs . Deux vulnérabilités distinctes permettent le forçage de signatures dans les implémentations RSA-PKCS et Ed25519.
Vulnérabilités concernées :
| CVE | Composant | Nature | Versions affectées |
|---|---|---|---|
| CVE-2026-33894 | RSA-PKCS#1 v1.5 | Accepte des signatures forgées avec exposant faible (e=3) | 0.1.2 à 1.3.3 |
| CVE-2026-33895 | Ed25519 | Accepte des signatures non-canoniques (S’ = S + k·L) | 0.7.4 à 1.3.3 |
1.2. Le mécanisme d’attaque
CVE-2026-33894 (RSA) :
- Le parseur ASN.1 accepte des structures DigestInfo non-canoniques (champs supplémentaires contrôlés par l’attaquant)
- La validation PKCS#1 n’impose pas les 8 octets minimum de padding requis
- Permet de forger des signatures valides, notamment avec des clés à faible exposant
CVE-2026-33895 (Ed25519) :
- La vérification n’effectue pas le contrôle de canonicité du scalaire S
- Une signature mutée (S + L) est acceptée comme valide
- Permet des attaques par substitution dans les systèmes reposant sur l’intégrité signature (logs d’audit, token binding)
1.3. Impact sur l’écosystème crypto
L’impact est potentiellement massif : toute application utilisant node-forge comme moteur unique de vérification est vulnérable . Cela inclut :
- Bibliothèques JOSE (node-jose)
- Outils de certification (Adobe, Expo)
- Intégrations PKI personnalisées
- Systèmes d’authentification et de signature de code
Exploitation : les preuves de concept publiques démontrent que l’attaque est réalisable à distance contre des endpoints effectuant la vérification. Le correctif est disponible dans la version 1.4.0 publiée le 5 avril 2026 .
2. La faille de signature du pont Wanchain : 9 millions de dollars volés
2.1. Une attaque par réutilisation de signature
En juillet 2026, le pont Wanchain entre Cardano et BNB Chain a été exploité, drainant environ 515 millions de tokens NIGHT (environ 9 millions de dollars) . Selon BlockSec, l’attaque provient d’une vulnérabilité de signature dans le validateur TreasuryCheck.
Le mécanisme :
- Le validateur combine 14 champs de longueurs variables sans séparateurs clairs
- Cette structure permet à différents ensembles de données de produire le même message signé
- Un attaquant peut réorganiser les valeurs des champs tout en conservant la signature valide
Le contrat contenait déjà la fonction Cardano SerialiseData qui aurait permis un encodage structuré, mais le pont ne l’utilisait pas pour construire le hash de signature .
2.2. Conséquences et réaction
| Élément | Détail |
|---|---|
| Montant volé | ~515 millions NIGHT (~9-10 M$) |
| Réaction du marché | Chute du token NIGHT de plus de 30 % en 24h |
| Infrastructure concernée | Infrastructure du pont Wanchain uniquement |
| Réseau Midnight | Confirmé comme sécurisé et non affecté |
La Midnight Foundation a clarifié que l’incident est isolé à l’infrastructure du pont tiers et n’implique pas le réseau principal Midnight .
3. Le backdoor @injectivelabs/sdk-ts : 49 minutes de compromission
3.1. Un package npm infecté
Le 8 juillet 2026, la version 1.20.21 du package npm @injectivelabs/sdk-ts (environ 175 000 téléchargements mensuels) a été publiée avec un module malveillant caché .
Chronologie :
| Heure (UTC) | Événement |
|---|---|
| 20:24:40 | Commit malveillant poussé sur GitHub (0121928) |
| 21:13:44 | Version 1.20.21 publiée sur npm |
| ~22:00 | Version 1.20.23 publiée (correctif) |
| Durée d’exposition | ~49 minutes |
3.2. Le mécanisme d’exfiltration
Le code malveillant, déguisé en « télémétrie de dérivation de clés », interceptait les deux points d’entrée principaux de dérivation de clés :
PrivateKey.fromMnemonic(): capture des phrases mnémoniques BIP-39PrivateKey.fromHex(): capture des clés privées brutes
Exfiltration :
- Les secrets capturés sont encodés en base64
- Ils sont dissimulés dans l’en-tête HTTP
X-Request-Id - Destination :
testnet.archival.chain.grpc-web.injective[.]network(un domaine conçu pour ressembler à un nœud archif légitime)
3.3. Leçon pour l’écosystème
La compromission est intervenue via un commit GitHub semblant provenir d’un mainteneur légitime . Bien que le package ait été corrigé en moins d’une heure, le risque d’utilisation par des développeurs ayant récupéré la version malveillante via des dépendances verrouillées reste réel.
4. L’attaque UNK_DeadDrop : le phishing ciblé des développeurs crypto
4.1. Une campagne nord-coréenne à grande échelle
Entre avril et mai 2026, Proofpoint a observé une campagne de phishing massive attribuée à un groupe probablement nord-coréen, baptisé UNK_DeadDrop .
Chiffres clés :
- Plus de 250 emails envoyés
- 100 organisations ciblées dans 12 secteurs
- Finance, cryptomonnaies, technologie, éducation en première ligne
- Cibles principalement aux États-Unis, mais répartition mondiale
4.2. L’infection chain : des dépôts GitHub piégés
La campagne exploite les développeurs comme vecteur d’entrée :
| Étape | Méthode |
|---|---|
| 1. Approche | Emails d’offres d’emploi pour « Full-Stack Engineer » ou demandes de peer review |
| 2. Piège | Liens vers dépôts GitHub contrefaits (projets crypto, archives d’exploits, tests Foundry) |
| 3. Infection | Extension VS Code malveillante (VSIX) s’exécute à l’ouverture du projet |
| 4. Exfiltration | Vol d’extensions wallets, identifiants décryptés, wallets de bureau |
| 5. Persistance | L’extension VSIX maintient l’accès après nettoyage des traces |
Dépôts identifiés :
| Nom du dépôt | Thème | Date de création |
|---|---|---|
| Pulsynk | Plateforme de prédiction crypto IA | 10 mai 2026 |
| Trixauvex | Moteur de trading crypto | 16 mai 2026 |
| rekt-db | Archive d’exploits blockchain (Bybit, Wormhole) | 19 mai 2026 |
| forge-4626-invariants | Tests Foundry pour vaults ERC-4626 | 20 mai 2026 |
| x402-kit | Infrastructure micropaiement HTTP 402 | 25 mai 2026 |
4.3. Une sophistication inquiétante
Les dépôts semblaient parfaitement légitimes :
- Structures de projet réalistes
- Scripts npm/forge fonctionnels
- Références à des standards réels
- Évolution active (6 builds avec modifications mineures)
L’attaque illustre l’évolution des groupes étatiques nord-coréens : ils ciblent désormais les développeurs crypto comme vecteur d’accès aux infrastructures et aux clés privées.
5. Litecoin MWEB : le double bug zero-day
5.1. Une attaque par transaction MWEB malformée
En avril 2026, une vulnérabilité zero-day dans la couche MWEB (MimbleWimble Extension Block) de Litecoin a été exploitée pour une attaque par déni de service .
Le mécanisme :
- Les attaquants ont crafté une transaction MWEB malformée
- Les nœuds non patchés l’ont acceptée comme valide (absence de validation des entrées)
- La transaction permettait de « peg out » des coins vers des DEX tiers sans autorisation
5.2. La réaction : une réorganisation de 13 blocs
Face à l’attaque, l’équipe Litecoin et les parties prenantes du réseau ont initié une réorganisation de 13 blocs :
- Rollback de l’état réseau avant l’inclusion des transactions invalides
- Effacement des transactions MWEB illégitimes de la chaîne canonique
- Transactions légitimes préservées
- Aucune perte de fonds pour les utilisateurs et exchanges
Leçon : le problème fondamental était le décalage d’application des correctifs . Tous les opérateurs de nœuds n’avaient pas appliqué les mises à jour récentes, laissant une fenêtre d’exploitation ouverte.
6. La vulnérabilité Zcash Zebra : contournement d’intégrité (CVE-2026-54496)
En juillet 2026, une vulnérabilité critique a été découverte dans l’implémentation Rust de Zcash, Zebra, affectant plusieurs composants .
CVE-2026-54496 :
- Le gadget de multiplication scalaire dans
halo2_gadgets/src/ecc/chip/mul/incomplete.rs - La fonction
assign_advice()n’applique pas de contrainte de copie reliant le point de base à la base réelle - Un prouveur malveillant peut produire une preuve valide pour une action Orchard avec un point de base sous-contraint
Conséquence : contournement du contrôle d’intégrité de l’adresse diversifiée qui lie pk_d, g_d, ivk, le nullifier (nf) et la clé de validation de dépense (ak) à la note dépensée.
Correctifs disponibles :
- zebrad 5.0.0
- halo2_gadgets 0.5.0
- orchard 0.14.0
- zcash_primitives 0.28.0
- zcashd 6.20.0
7. La campagne Operation Zero : un marché des exploits en cryptomonnaies
7.1. Une entreprise de zero-day financée en crypto
En février 2026, l’OFAC américain a sanctionné Operation Zero (Matrix LLC), une société russe spécialisée dans le commerce d’exploits zero-day, accusée d’avoir utilisé des cryptomonnaies pour financer le vol de secrets commerciaux américains .
Le schéma :
| Acteur | Rôle |
|---|---|
| Peter Williams (Australien) | A volé des logiciels propriétaires d’un sous-traitant de la défense américaine |
| Operation Zero (Russe) | A acheté les données volées avec des millions de dollars en cryptomonnaies |
| Gouvernement russe | Destinataire ultime des technologies sensibles |
7.2. Une nouvelle forme de menace crypto
Operation Zero est une plateforme de bug bounty inversée : elle paie des hackers pour identifier et exploiter des vulnérabilités, puis revend les exploits à des acheteurs étatiques . L’utilisation de cryptomonnaies pour ces transactions illustre un financement de la cybercriminalité directement adossé aux actifs numériques.
8. Recommandations pour 2026
8.1. Pour les développeurs et protocoles
| Action | Priorité |
|---|---|
| Mettre à jour node-forge vers v1.4.0 | Urgente |
| Auditer les dépendances npm et leurs verrous | Haute |
| Vérifier l’intégrité des packages téléchargés | Haute |
| Ne jamais faire confiance à des dépôts GitHub non vérifiés | Élevée |
| Imposer des délais d’application des correctifs | Élevée |
8.2. Pour les opérateurs de nœuds
- Appliquer immédiatement les patches de sécurité (ex: Litecoin MWEB)
- Établir une politique de mise à jour stricte
- Surveiller les événements de réorganisation de chaîne
8.3. Pour les utilisateurs
- Se méfier des offres d’emploi LinkedIn proposant des tests techniques sur GitHub
- Vérifier l’authenticité des projets avant de cloner des dépôts
- Mettre à jour régulièrement les applications et les dépendances
Conclusion
Les attaques zero-day crypto en 2026 révèlent une évolution profonde des menaces. Les hackers, notamment les groupes étatiques nord-coréens, ne se contentent plus d’exploiter les smart contracts : ils ciblent désormais les chaînes d’approvisionnement logicielles (SDK, bibliothèques, packages npm), les infrastructures de ponts (Wanchain) et les développeurs eux-mêmes (UNK_DeadDrop).
L’affaire node-forge démontre que des bibliothèques cryptographiques fondamentales peuvent contenir des failles critiques pendant des années. Le backdoor Injective illustre la rapidité avec laquelle un package légitime peut être compromis. La faille Wanchain rappelle que la construction des messages de signature doit être canonique et sans ambiguïté.
La protection contre les zero-days en 2026 ne peut plus reposer sur la simple correction de failles isolées. Elle exige une refonte des pratiques de sécurité : audits des dépendances, vérification d’intégrité, application rigoureuse des correctifs, et une vigilance permanente face aux menaces ciblant les infrastructures et les développeurs.
