Imaginez une banque suisse creusée directement dans la roche.
À l'entrée se trouvent des hérissons antichacks. Les portails sont en titane d'un mètre d'épaisseur. À l'intérieur, des détecteurs de mouvement, de la biométrie, des gardes armés et un coffre-fort impossible à ouvrir avec une seule clé. Pendant des années, la banque montre cette forteresse dans ses spots publicitaires pour que les déposants dorment sur leurs deux oreilles.
Mais une banque doit fonctionner.
C'est pourquoi, sur le flanc de la montagne, il existe une petite porte technique. Par celle-ci passent les ingénieurs, les coursiers, le service comptable, les équipes de maintenance et des milliers d'ordres internes : transférer des fonds, confirmer un paiement, mettre à jour un solde, ouvrir une écluse.
Et une nuit, les attaquants ne s'approchent même pas des portes en titane.
Ils obtiennent l'accès au couloir de service.
Puis le pire se produit.
On ne force pas le coffre.
Le coffre reçoit un ordre correctement rédigé et remet de lui-même l'argent.
C'est précisément pourquoi ce qui est arrivé le 29 octobre 2026 à Binance s'avère bien plus intéressant qu'une énième histoire de « hackers ayant volé de la crypto ».
Selon l'estimation de Binance elle-même, l'ampleur de l'incident s'élève à environ 6,3 milliards de dollars. L'entreprise a indiqué qu'environ 3 milliards de dollars ont pu être gelés et que les pertes seront couvertes par le fonds SAFU et ses propres fonds. L'enquête préliminaire de Binance pointe du doigt une compromission potentielle de l'ordinateur portable d'un ingénieur DevOps, à la suite de laquelle l'attaquant a eu accès au conteneur de service et a pu envoyer des requêtes de retrait non autorisées. Binance souligne par ailleurs : aucune preuve de fuite de clés privées n'a été découverte pour l'instant.
Communiqué officiel de Binance concernant le piratage
Et cette dernière phrase s'avère bien plus terrifiante que les premières.
Car si les clés privées n'ont effectivement pas été volées, une autre question se pose :
qui a alors signé les transactions ?
Pour ceux à qui il suffit de comprendre ce qui s'est passé
Imaginez la signature électronique du directeur d'une entreprise.
Le voleur n'a ni volé la signature elle-même ni appris à la falsifier. Il a pénétré dans le système comptable interne et a d'une manière ou d'une autre poussé le mécanisme d'entreprise légal à signer ses ordres de paiement.
À la sortie, la banque voit un document authentique.
La signature est authentique.
Le format est authentique.
Le système dit : tout va bien.
Sauf que l'argent part chez le criminel.
C'est exactement le tableau que dresse actuellement l'analyse forensique de la blockchain.
TRM Labs a retracé environ 6,36 milliards de dollars ayant quitté les portefeuilles liés à Binance sur pas moins de dix blockchains. La majeure partie des actifs a été déplacée en l'espace d'environ vingt minutes. Ethereum, Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche, Polygon. Il ne s'agit pas d'un portefeuille oublié ni d'un smart contract louche.
Chainalysis a de son côté indiqué à Reuters que vers 00:30 GMT, ses spécialistes avaient confirmé le vol d'au moins 5,912 milliards de dollars. À ce stade, Chainalysis ne confirmait pas encore définitivement la cause de l'attaque.
Par son ampleur, il s'agit du plus grand braquage crypto de l'histoire. Le précédent record monstrueux de Bybit en février 2025 s'élevait à environ 1,5 milliard de dollars.
Et voici le point le plus important.
Bitcoin n'a pas été piraté. Ethereum n'a pas été piraté. La cryptographie n'a pas été vaincue.
Les systèmes ont reçu des signatures valides et ont exécuté les commandes.
Si cette explication vous suffit, vous pouvez fermer cet article.
Sérieusement.
Allez continuer à faire défiler TikTok, regarder des chats et débattre de la direction du Bitcoin demain. Pour l'utilisateur lambda, la conclusion principale est déjà tombée : la plus grande bourse de crypto-monnaies au monde a subi un choc d'environ 6,3 milliards de dollars, non pas parce que quelqu'un a mathématiquement « cassé la blockchain ».
La suite abordera l'EIP-7702, le nonce, l'infrastructure de signature, les frontières de confiance et la question très inconfortable de ce que signifie réellement le mot « sécurisé » dans un système distribué moderne.
Les ingénieurs peuvent rester.
Partie II. La forteresse n'a pas été fracturée. Elle a ouvert ses portes d'elle-même
L'indice le plus intéressant est apparu sur Ethereum.
En mai 2025, avec la mise à jour Pectra, Ethereum a intégré le mécanisme EIP-7702. Celui-ci permet à un compte externe ordinaire (Externally Owned Account) d'acquérir temporairement un comportement programmable via la délégation de l'exécution d'un smart contract.
En soi, l'EIP-7702 n'est pas une vulnérabilité.
Il s'agit d'une fonctionnalité standard d'Ethereum.
Selon la spécification officielle, l'autorisation contient, entre autres, l'ID de la chaîne, l'adresse du code délégué, le nonce et la signature cryptographique du propriétaire du compte. Une fois l'autorisation correctement effectuée, les appels du compte peuvent exécuter le code du contrat spécifié.
Spécification officielle Ethereum EIP-7702
Et c'est là que commence la beauté du cauchemar d'ingénierie.
Selon TRM Labs, l'attaquant s'est procuré à l'avance 50 autorisations EIP-7702 signées pour des nonces consécutifs du hot wallet de Binance.
Pourquoi cinquante ?
Parce qu'un hot wallet est actif. Il effectue constamment des opérations et son nonce change.
Plutôt que de tenter de deviner un état unique, l'attaquant disposait d'une série d'autorisations pré-signées. Lorsque la transaction est entrée sur le réseau, l'une d'elles a coïncidé avec le nonce actuel.
Cela a suffi.
À 20:20 UTC, le portefeuille de Binance a été délégué à un contrat de type sweeper (aspirateur) contrôlé par l'opérateur de l'attaque.
3 minutes et 24 secondes après la délégation, 167 464 ETH et 63 autres jetons, dont environ 1,615 milliard de USDT, ont quitté le portefeuille en une seule opération. La délégation a continué à fonctionner, et les fonds reçus ultérieurement ont de nouveau été siphonnés.
Mais si l'histoire s'était arrêtée là, tout aurait pu être mis sur le compte d'une anomalie spécifique à Ethereum.
Elle ne s'est pas arrêtée là.
Dix blockchains réduisent en miettes la version simpliste de l'attaque
Presque simultanément, l'argent a commencé à quitter les portefeuilles de Binance sur d'autres réseaux.
Et là-bas, point d'EIP-7702.
Bitcoin utilise un autre modèle.
XRP Ledger un autre.
Tron un autre.
Solana un autre.
Pourtant, les portefeuilles associés à Binance continuaient à générer des transactions signées de manière valide au profit d'un même circuit d'attaque.
TRM en tire donc une conclusion cruciale : il est hautement probable que le malfaiteur ait réussi à contraindre l'infrastructure de signature des hot wallets de Binance à signer les transactions de son choix simultanément pour plusieurs réseaux. Binance n'a pas encore publié la cause définitive.
C'est ici que s'arrête l'histoire de « l'ordinateur portable infecté ».
Plus précisément, l'ordinateur portable reste important, mais son rôle change.
La compromission de la station de travail d'un ingénieur DevOps peut tout à fait expliquer l'accès initial (initial access).
Elle n'explique toujours pas autre chose :
pourquoi la compromission d'un seul point de travail a-t-elle permis d'atteindre le périmètre de confiance capable d'autoriser le retrait de milliards de dollars sur de multiples blockchains ?
Ce sont là des questions fondamentalement différentes.
L'entrée dans la banque et la capacité d'ordonner au coffre de délivrer de l'or ne devraient pas relever du même niveau d'accès.
Partie III. Éloignez maintenant les enfants des écrans : l'architecture entre en scène
Une bourse de crypto-monnaies moderne ne stocke pas des milliards de dollars dans un fichier wallet.dat sur l'ordinateur portable d'un administrateur.
Entre l'utilisateur qui clique sur le bouton Retrait et la transaction blockchain effective, il existe une longue chaîne de confiance.
Le front-end accepte la requête.
Le système d'identité identifie l'utilisateur.
Le moteur de risque évalue l'opération.
Le service de retrait forme la transaction.
La couche de politiques (policy layer) vérifie les limites, l'adresse, le réseau et le contexte.
L'infrastructure de signature crée la signature cryptographique.
Le service de diffusion envoie le résultat sur la blockchain.
Dans une architecture normale, la compromission d'un seul élément de cette chaîne ne doit pas entraîner automatiquement la compromission des autres.
C'est précisément ici qu'intervient la principale hypothèse d'ingénierie de cette enquête.
Nous ne savons pas encore si les attaquants ont volé des identifiants IAM, des jetons d'identité de charge de travail (workload identity), des jetons d'API internes, l'accès à l'orchestration des signatures ou s'ils ont compromis un autre composant du plan de contrôle (control plane). Binance n'a pas encore publié de post-mortem technique.
Affirmer par conséquent que « les hackers ont volé le jeton maître de Vault », « cassé le MPC » ou « pris le contrôle du control plane Kubernetes » relèverait actuellement de la pure fantaisie journalistique.
Cependant, la blockchain nous laisse un indice beaucoup plus tangible :
quelqu'un a obtenu les signatures valides de Binance pour des opérations que Binance n'avait nullement l'intention d'effectuer.
Et ce, sur plusieurs réseaux.
Il ne s'agit plus là d'une hypothèse de virus sur un ordinateur portable, mais bien de la conséquence observable du fonctionnement du système.
Pourquoi le MPC et les HSM ne constituent pas un bouclier magique ici
Après de telles attaques, une question surgit presque inévitablement :
« Les grandes bourses n'utilisent-elles pas des HSM, du multisig et du MPC ? »
Elles utilisent des systèmes de défense complexes.
Mais c'est là que réside l'une des erreurs conceptuelles les plus désagréables de la cybersécurité moderne.
La protection d'une clé et la protection de la décision de signer une transaction relèvent de tâches différentes.
Il est possible de construire un HSM dont il est physiquement impossible d'extraire la clé privée.
Il est possible de diviser un secret entre plusieurs nœuds MPC de sorte qu'aucune clé complète n'existe jamais au même endroit.
Il est possible de concevoir une cryptographie magnifique.
Mais si la couche d'orchestration de confiance indique à ces composants :
Cette transaction est autorisée. Signe.
et que la politique de vérification juge la requête légitime, le système cryptographique fera honnêtement son travail.
Il n'aura pas été piraté.
Il a été utilisé correctement à de mauvaises fins.
Il s'agit d'une classe de catastrophe fondamentalement différente.
Le Zero Trust qui s'est arrêté devant la porte du signataire
Le NIST a formulé le principe du Zero Trust de manière on ne peut plus simple : aucun utilisateur ou ressource ne doit se voir accorder une confiance automatique au seul motif qu'il se trouve « à l'intérieur » du réseau d'entreprise ou qu'il appartient à l'organisation. L'autorisation doit s'articuler autour d'un utilisateur, d'un appareil, d'une ressource et d'une action spécifiques.
NIST SP 800-207 : Zero Trust Architecture
Mais l'infrastructure financière exige une version encore plus stricte de ce principe.
Il ne suffit pas de demander :
« Ce service a-t-il le droit d'appeler le système de signature ? »
Il faut se demander :
« Ce service a-t-il le droit de signer précisément cette transaction, pour ce montant exact, sur ce réseau précis, vers cette adresse, dès à présent et à la suite d'une telle séquence d'événements ? »
Il ne s'agit plus d'authentification.
Il s'agit d'autorisation sémantique (semantic authorization).
Et c'est précisément là, à en juger par le résultat observable de l'attaque, que se situe la principale leçon tirée par Binance.
Cinquante signatures qui auraient dû faire passer tout le datacenter au rouge
Le détail le plus alarmant de l'enquête de TRM n'est même pas le montant de 6,3 milliards de dollars.
Ce sont les cinquante autorisations EIP-7702 préparées à l'avance.
Pour le portefeuille d'un utilisateur lambda, l'EIP-7702 peut constituer un outil utile d'abstraction de compte.
Pour l'infrastructure de trésorerie/hot wallet d'une bourse, une série inattendue de telles autorisations devrait ressembler à un employé de banque qui, à trois heures du matin, apporte cinquante ordres pré-signés :
« Si le coffre se trouve actuellement à l'état n°18 914 775, transférer le contrôle à cette personne. S'il est déjà au n°18 914 776, utiliser le document suivant... »
Ce n'est pas une transaction ordinaire.
Il s'agit d'une modification du modèle de gestion d'un compte.
TRM recommande explicitement aux équipes de trésorerie de surveiller la délégation EIP-7702, d'interdire de telles autorisations par politique lorsqu'elles ne sont pas attendues, de considérer une série d'autorisations pour une plage de nonces comme un indicateur de compromission, et de cloisonner l'infrastructure de signature et les chemins d'approbation par réseaux et par niveaux de portefeuilles.
Ceci n'est plus de la théorie.
Ce sont les recommandations d'une équipe d'investigation forensique à la suite du plus grand braquage crypto de l'histoire.
Où la sécurité a réellement failli
À mon sens, la principale leçon à retenir de Binance n'est pas qu'il « ne faut pas faire confiance aux employés », qu'il « ne faut pas utiliser de hot wallets » ou que « l'EIP-7702 est dangereux ».
Ce sont là des conclusions bien trop simplistes.
C'est le modèle de confiance transitive lui-même qui s'est effondré.
Si la station de travail fait confiance au conteneur de service, que le conteneur fait confiance au service de retrait, que le service de retrait fait confiance au moteur de politiques, et que ce dernier est capable de convaincre l'infrastructure de signature que l'opération est légitime, l'attaquant n'a nullement besoin de briser le dernier rempart.
Il lui suffit de s'emparer d'un tronçon de la chaîne après quoi le système continuera à se faire confiance à lui-même.
Dans l'ancien modèle de sécurité, on protégeait la clé.
Dans le nouveau, il faudra protéger l'intention (intent).
Le système de signature du futur devra comprendre non seulement :
signature autorisée
mais aussi :
pourquoi cette opération existe.
Un retrait de plusieurs milliards ne doit pas devenir admissible au seul motif que la requête provient d'un service correctement authentifié.
Il est impératif de mettre en place des domaines de politiques indépendants, des limites strictes de rayon d'impact (blast-radius limits), une segmentation des portefeuilles par réseaux et fonctions, des plans d'approbation distincts, un contrôle comportemental des volumes, la simulation des transactions, des politiques de destination, des coupe-circuits (circuit breakers) indépendants et la capacité d'arrêter automatiquement l'infrastructure de signature en cas de modification anormale du comportement d'un portefeuille.
Le mot clé ici est : indépendants.
Si le même plan de contrôle génère simultanément la transaction, en confirme l'admissibilité et obtient la signature, aucun nombre de jolis badges verts Security Certified ne sauvera l'architecture d'une compromission de ce control plane.
La piste nord-coréenne
TRM Labs associe avec un haut degré de certitude l'opération à TraderTraitor, le cluster de hackers étatiques nord-coréens. L'entreprise pointe des indices on-chain et off-chain, la préparation préalable de l'opération, l'utilisation de Tornado Cash pour financer le portefeuille de l'opérateur, les tests d'infrastructure menés avant l'attaque et les signatures obtenues au préalable.
Il s'agit pour l'instant d'une attribution relevant du renseignement blockchain, et non d'une conclusion finale publiée par les autorités répressives concernant Binance.
Le paradoxe le plus déplaisant de toute cette affaire
Environ la moitié des fonds dérobés a pu être stoppée non pas grâce à la blockchain.
Mais grâce à la centralisation.
Tether a pu geler des USDT.
Circle a bloqué des USDC.
Ripple a gelé une partie des RLUSD.
World Liberty Financial a bloqué des USD1.
Le comité de sécurité d'Arbitrum (Arbitrum Security Council) a exercé ses pouvoirs d'urgence.
Selon les calculs préliminaires de TRM, cela a permis d'intercepter environ 2,7 milliards de dollars, tandis que Binance a fait état ultérieurement d'environ 3 milliards de dollars d'actifs gelés.
Ce qui donne lieu à un formidable paradoxe philosophique du monde des crypto-monnaies.
La centralisation a créé un point de concentration de risque gigantesque.
Et lorsque ce point s'est effondré, une autre centralisation a contribué à récupérer une partie de l'argent.
L'USDT peut être gelé précisément parce qu'il existe un émetteur.
Le Bitcoin ne peut pas être gelé précisément parce qu'un tel émetteur n'existe pas.
La décentralisation est à la fois une protection et un problème.
La centralisation est à la fois un problème et un frein d'urgence.
Ce qui va suivre
Après Binance, l'industrie va presque certainement réexaminer non seulement les modes de stockage des clés, mais aussi l'architecture d'autorisation des signatures.
Les HSM resteront.
Le MPC restera.
Le stockage à froid (cold storage) restera.
Mais la simple déclaration « les clés privées n'ont pas fuité » ne suffira plus.
Car le plus grand braquage crypto peut survenir sans qu'il soit besoin de sortir une clé privée d'un coffre sécurisé.
La prochaine génération de sécurité financière s'articulera autour de la question :
qui, pourquoi et dans quelles circonstances est en mesure de contraindre une clé à signer une action spécifique ?
Cela implique une transition de la sécurité des clés (Key Security) vers la sécurité des intentions (Intent Security).
Passer de la protection du secret à la protection de la décision.
Passer de « nous faisons confiance au service interne » à « nous ne faisons pas confiance, même à notre propre service, tant qu'une opération spécifique n'a pas prouvé sa légitimité ».
Et c'est là qu'il faudra enfin mener l'ancien Zero Trust à sa conclusion logique.
Ne faites pas confiance à l'utilisateur.
Ne faites pas confiance à l'appareil.
Ne faites pas confiance au réseau.
Ne faites pas confiance au conteneur.
Ne faites pas confiance à l'API.
Et par-dessus tout :
ne faites pas confiance, même à une signature cryptographique valide, tant que vous ne comprenez pas pourquoi le système a décidé de la générer.
La forteresse du XXIe siècle
Binance poursuit son enquête. Aucun post-mortem technique complet n'a encore été publié, il est donc prématuré de statuer définitivement sur la chaîne d'accès initial précise ou sur le schéma de compromission interne.
C'est pourquoi il importe aujourd'hui de ne pas transformer l'enquête en théorie du complot.
Nous n'en avons pas besoin.
Les faits se suffisent à eux-mêmes pour faire peur.
Environ 6,3 milliards de dollars d'impact.
Dix blockchains.
Des dizaines de portefeuilles.
Des signatures valides.
Cinquante autorisations EIP-7702 pré-signées.
Environ vingt minutes pour la phase principale.
Et la plus grande bourse crypto au monde n'ayant pour l'instant découvert aucune preuve de fuite de clés privées.
L'ancienne forteresse bancaire était construite autour du coffre-fort.
La forteresse numérique a été construite autour de la clé cryptographique.
Il s'avère pourtant que le voleur du XXIe siècle peut tout à fait se passer de toucher au coffre.
Il pénètre dans la salle de contrôle.
Modifie l'itinéraire.
Transmet la bonne commande.
Et le système ouvre la porte de lui-même.
La cryptographie n'a pas été fracturée.
La forteresse a elle-même signé son propre braquage.
Sources et base technique
TRM Labs : analyse on-chain complète de l'attaque à 6,36 milliards de dollars
Reuters : estimations de Chainalysis et réaction des spécialistes du secteur
Ethereum Improvement Proposals : spécification officielle de l'EIP-7702