Piratage de Binance : comment l’attaque de 6,3 milliards de dollars s’est déroulée

Montrer le sommaire Cacher le sommaire

• Qu’est‑ce que EIP‑7702 et pourquoi la délégation a facilité le vol
  • Nuances opérationnelles
• Comment sait‑on que l’attaque a été planifiée plusieurs heures à l’avance
• Les signatures étaient‑elles volées ou légitimes mais détournées
• Comment certains fonds ont pu être gelés et quelles sont les limites de ces gels
• Quelles erreurs opérationnelles ont facilité l’attaque et que faut‑il changer
• Que cherchent encore les enquêteurs et pourquoi certaines questions restent ouvertes
• Que pouvez‑vous faire si vous détenez des cryptos sur un exchange
• Leçons pour l’écosystème et limites des réponses techniques
• FAQ

Le piratage massif de Binance en octobre 2026 a remis sur le devant de la scène une vulnérabilité peu comprise du grand public et des professionnels, mêlant nouvelles spécificités d’Ethereum, procédés multichaînes et pratiques opérationnelles fragiles. Au-delà des milliards détournés et des gels partiels, ce qui importe pour l’avenir, c’est de comprendre comment une autorisation cryptographique a pu se transformer en contrôle persistant, et quelles leçons pratiques en tirer pour les exchanges, les développeurs et les utilisateurs.

Qu’est‑ce que EIP‑7702 et pourquoi la délégation a facilité le vol

EIP‑7702 est une évolution d’Ethereum pensée pour permettre à un compte classique d’autoriser un smart contract à exécuter en son nom. Conçu pour déléguer des actions répétitives sans gérer de clés supplémentaires, le mécanisme devient dangereux si la gestion des autorisations est laxiste.

Dans les faits, la délégation permet deux actions utiles et problématiques selon le contexte. La fonction dite sweep transfère automatiquement les tokens d’un compte vers une adresse tierce. La fonction forward exécute des appels sur d’autres contrats en prenant pour origine le compte délégué. Conjuguées, ces fonctions donnent la capacité de vider un portefeuille et d’interagir ensuite avec des protocoles DeFi depuis l’adresse compromise.

Nuances opérationnelles

La délégation n’exige pas de nouvelle signature pour chaque transfert. C’est précisément ce qui a transformé une autorisation ponctuelle en contrôle persistant sur plusieurs heures. Dans la pratique, les équipes de sécurité doivent traiter ces autorisations comme des clés à part entière et appliquer le principe du moindre privilège et des durées d’expiration.

Comment sait‑on que l’attaque a été planifiée plusieurs heures à l’avance

Les recherches on‑chain montrent une série d’étapes préparatoires classiques d’une opération sophistiquée. Les attaquants ont d’abord testé des contrats et des mécanismes sur leurs propres wallets, envoyé de petits montants à travers Tornado Cash, puis déployé un contrat sweeper avant de déclencher la phase active. Ces étapes sont typiques d’une attaque bien orchestrée et non d’un phishing opportuniste.

Moment UTC	Action identifiée
~36 heures avant	Transactions tests depuis Tornado Cash vers un wallet contrôlé
~24 heures avant	Déploiement d’un contrat sweeper et essais sur wallets de test
20h24 UTC	Premier vidage massif du wallet Ethereum connu comme Binance 14
00h10 UTC	Révocation de la délégation, après plusieurs vidages

La répétition et la logique des tests laissent peu de doute sur l’intention. Les attaquants avaient conçu un enchaînement précis pour maximiser la vitesse d’extraction avant que les mesures de mitigation puissent intervenir.

Les signatures étaient‑elles volées ou légitimes mais détournées

Une signature valide signifie que l’opération a été approuvée par la clé correspondante, pas qu’elle a été ordonnée par un humain légitime. Les scénarios probables sont variés. Dans certains cas, des clés privées fuient hors des HSM ou systèmes MPC. Dans d’autres, la chaîne de signature est compromise : un service applicatif, un moteur de politiques ou un conteneur peut produire des signatures valides sur des transactions frauduleuses sans que les clés aient jamais quitté leur coffre.

En pratique, déterminer la cause demande des audits internes détaillés. Les indices multichaînes observés pendant l’attaque — signatures valides sur Bitcoin, Ethereum et Solana en quelques minutes — suggèrent l’accès à une infrastructure capable d’orchestrer des signatures sur plusieurs piles technologiques, plutôt qu’un simple vol ponctuel d’une clé Ethereum isolée.

Comment certains fonds ont pu être gelés et quelles sont les limites de ces gels

Les gels réussis reflètent deux types de leviers. Les émetteurs de stablecoins contrôlés peuvent refuser ou blacklister des adresses et ainsi rendre certains actifs inutilisables. Au niveau protocole, des gouvernances comme celle d’Arbitrum peuvent temporairement déplacer ou bloquer des fonds dans des circonstances d’urgence. Ces actions ont permis de sécuriser environ la moitié du montant volé.

Cependant, plusieurs limites apparaissent.

• Les jetons non centralisés et les bitcoins ne peuvent pas être simplement « gelés » sans coopération des plateformes où ils circulent.
• Les attaquants peuvent convertire rapidement des stablecoins en autres actifs ou emprunter contre des garanties pour contourner les gels.
• Les gels sont soumis aux juridictions et à la bonne volonté des émetteurs, ce qui complique la récupération automatique des fonds.

Quelles erreurs opérationnelles ont facilité l’attaque et que faut‑il changer

Les pratiques courantes observées dans de nombreuses analyses renseignent sur des faiblesses répétées. L’utilisation d’un appareil personnel ou d’un laptop d’ingénieur pour des actions sensibles, des accès trop larges à des services pouvant soumettre des transactions, des hot wallets contenant des réserves trop importantes et un manque d’alertes adaptées aux délégations persistantes créent un terrain favorable aux attaquants.

Mesures concrètes recommandées

• Segmenter les environnements entre dev, staging et production et interdire les accès directs depuis des laptops non gérés.
• Limiter la taille des hot wallets et instituer des seuils d’alerte pour tout flux inhabituel.
• Traiter les délégations comme des clés avec expirations automatiques et audits réguliers.
• Utiliser HSM ou MPC pour la gestion des clés et restreindre les chemins d’accès à la chaîne de signature.
• Mettre en place des playbooks d’incident et des exercices de simulation pour réduire le délai de réponse.

Que cherchent encore les enquêteurs et pourquoi certaines questions restent ouvertes

Plusieurs points clés restent à établir publiquement. Comment l’accès initial a‑t‑il été obtenu ? Quels composants exacts de la chaîne de signature ont été manipulés ? Le portefeuille Bitcoin compromis était‑il réellement un cold wallet ou un hot wallet déguisé ? Ces interrogations conditionnent la nature des remèdes et les responsabilités.

La complexité technique des infrastructures modernes, l’existence de multiples fournisseurs tiers et le manque de transparence immédiate rendent la reconstitution difficile. Les rapports publics partiels livrent des indices mais pas encore la cartographie complète des compromis.

Que pouvez‑vous faire si vous détenez des cryptos sur un exchange

Pour la plupart des utilisateurs, la meilleure règle reste la prudence. Voici des actions rapides et réalistes à envisager aujourd’hui.

• Ne laissez sur un exchange que ce dont vous avez besoin pour trader.
• Pour des montants significatifs, privilégiez des portefeuilles matériels ou des solutions multisig chez des prestataires réputés.
• Activez toutes les protections d’accès proposées par la plateforme, notamment les whitelists d’adresses et les retraits avec délai.
• Surveillez les alertes on‑chain via des services publics pour détecter tout mouvement suspect lié à vos dépôts.

Leçons pour l’écosystème et limites des réponses techniques

Le cas montre que l’innovation protocolaire apporte à la fois des capacités et des risques. Les mécanismes comme EIP‑7702 ont des usages légitimes mais exigent une gouvernance et des contrôles rigoureux. Techniquement, rien n’est inviolable ; il s’agit plutôt d’empiler des protections, de limiter la surface d’attaque et d’améliorer la détection.

Politiquement et juridiquement, la situation révèle aussi des limites. Les gels et interventions de gouvernance fonctionnent quand il existe des acteurs centralisés ou une gouvernance active. Pour les actifs réellement décentralisés, la traçabilité on‑chain aide les enquêtes mais n’assure pas la restitution sans coopération internationale et judiciaire.

FAQ

Qui est responsable du piratage de Binance en 2026
À ce stade, aucune attribution publique définitive n’a été confirmée. Les enquêtes techniques montrent une opération sophistiquée impliquant un accès multifacette, mais l’origine exacte des attaquants reste indéterminée.

Qu’est‑ce que EIP‑7702
EIP‑7702 est un mécanisme d’Ethereum permettant à un Externally Owned Account d’autoriser un smart contract à exécuter des actions en son nom. Utile mais dangereux si les autorisations persistent sans contrôle.

Les fonds volés peuvent‑ils être récupérés
Une partie a été gelée grâce à des actions d’émetteurs et de gouvernances. La récupération totale dépendra des procédures juridiques, de la coopération des plateformes et de la capacité à localiser et neutraliser les adresses encore actives.

Comment savoir si mes cryptos sont en sécurité sur un exchange
Vérifiez la taille des hot wallets déclarés, les mesures de sécurité publiques, les assurances, l’existence de procédures de récupération et activez toutes les protections proposées. Ne confiez jamais plus que nécessaire à une plateforme.

Qu’est‑ce qu’une chaîne de signature détournée
C’est une situation où des signatures valides sont produites par l’infrastructure d’un service sans que la demande d’opération ait été légitime. La clé peut rester protégée, mais les contrôles en amont ont été contournés.

Les stablecoins peuvent‑ils toujours être bloqués après un vol
Oui si l’émetteur centralisé décide de blacklister des adresses ou de ne plus reconnaître certains transferts. Cela fonctionne pour les tokens centralisés mais pas pour les cryptos vraiment décentralisées sans émetteur central.