L'article original provient de la société de sécurité Web3 blockaid
Compilé par Expressman@Odaily Planet Daily
Résumé de l'incident
Le 29 octobre 2026, selon les statistiques publiques, les portefeuilles chauds de Binance sur six chaînes—Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin et Tron—ont été dérobés d'au moins 5,5 milliards de dollars, le plus grand vol de cryptomonnaies jamais enregistré publiquement. L'attaque s'est concentrée sur Binance 14 (Binance 14)—l'un des portefeuilles chauds les plus importants et les plus actifs de Binance sur Ethereum.
À partir de 20h24 UTC, l'attaquant a d'abord vidé Binance 14 avec une transaction d'environ 2,5 milliards de dollars. Quelques minutes plus tôt, une autorisation EIP-7702 signée avec une copie de la clé privée du portefeuille a dirigé la délégation du portefeuille vers un contrat sweeper déployé par l'attaquant. Dans les 12 minutes suivant le premier balayage, 10 autres portefeuilles chauds de Binance sur quatre chaînes ont envoyé des fonds à la même adresse ; par la suite, l'attaquant a utilisé Binance 14, toujours délégué, pour vider un compte intelligent au nom de Binance. Binance a déclaré enquêter et n'a pas confirmé si les fonds des utilisateurs ont été affectés. À ce jour, les balayages totalisent 5,5 milliards de dollars, et l'exploit est toujours en cours.
La détection de Blockaid a signalé le balayage dans les deux minutes suivant sa survenue, avant tout rapport public, et une analyse automatisée a confirmé la fuite de clé privée et le mécanisme de délégation en 11 minutes. En une heure, Blockaid a marqué les adresses de l'attaquant comme malveillantes sur son réseau, a notifié tous les clients de l'incident via le Flux d'incidents de l'écosystème, et a suivi l'ensemble du processus de dispersion, d'échange et d'utilisation des fonds comme collatéral pour des prêts. Tether et Circle ont gelé environ 1,8 milliard de dollars sur l'adresse de réception principale ; Tether a ensuite déclaré que le total des USDT qu'elle avait gelés dépassait 1,5 milliard de dollars. Les ETH, AVAX, OP et ARB qui n'ont pas pu être gelés restent entre les mains de l'attaquant.
Ce rapport couvre le processus de préparation de l'attaquant, la délégation et le balayage EIP-7702, la signature parallèle de clés privées sur quatre chaînes, les voies de blanchiment d'argent et le gel. Il est rédigé pour les exchanges, les dépositaires et les institutions financières qui détiennent des clés de signature à grande échelle, en pointant les deux points de contrôle qui déterminent le succès ou l'échec de telles attaques : l'application des politiques avant la production des signatures, et la surveillance continue après le début du mouvement des fonds.
Contexte : portefeuilles chauds, clés de signature et délégation EIP-7702
Les portefeuilles chauds des exchanges sont des comptes en ligne utilisés par les exchanges pour traiter les retraits des clients et transférer des fonds entre leurs propres portefeuilles. Ils détiennent d'importantes quantités de capital de travail, signent en continu, souvent des milliers de transferts par jour ; et les clés privées derrière ces signatures sont la seule ligne de défense entre le solde et quiconque détient une copie de la clé privée. Sur Ethereum et les autres chaînes EVM, ces portefeuilles ont historiquement été des comptes détenus en externe (EOA)—des adresses ordinaires sans code, où une seule signature valide peut déplacer des fonds, et rien d'autre n'est vérifié on-chain.
EIP-7702 permet à un EOA d'exécuter du code de contrat intelligent. Le compte signe une autorisation spécifiant un contrat ; une fois qu'une transaction de type 4 empaquette cette autorisation dans un bloc, tout appel à ce compte exécutera la logique de ce contrat avec un accès complet au solde du compte. L'autorisation est liée au nonce du compte, et la délégation reste effective jusqu'à ce que le compte signe une nouvelle autorisation pour la remplacer ou l'effacer. Pour les portefeuilles de détail, cela permet les transactions par lots et le parrainage de gas ; pour les portefeuilles chauds, une seule signature divulguée atterrissant sur le bon nonce équivaut à remettre à l'attaquant un contrôle continu, au niveau du code, du compte, y compris chaque dépôt ultérieur.
Blockaid a vérifié 4 incidents EIP-7702 au cours du premier semestre 2026, impliquant un total d'environ 1,08 million de dollars, chacun abusant d'un aspect différent de la délégation ; son « Rapport de sécurité onchain H1 2026 » prévoyait que le premier cas à sept chiffres apparaîtrait avant la fin de l'année. Cet incident est la réalisation de cette prédiction, et de trois ordres de grandeur supérieur à la prédiction.
Le chemin de transfert direct est plus ancien et plus simple : une clé privée volée signe des transferts ordinaires, qui, sur un portefeuille qui envoie des milliers de retraits par jour, semblent routiniers jusqu'à ce que le destinataire, le montant et le moment soient examinés ensemble. Les deux chemins reposent en fin de compte sur des clés privées—c'est pourquoi la détection de ce type d'attaque repose sur des caractéristiques comportementales, et non sur des schémas de signature connus ou des vulnérabilités de contrat.
Le processus complet de l'exploit
Toutes les heures ci-dessous sont en UTC le 29 octobre 2026 ; l'incident était encore en cours d'évolution au moment de la publication.
1. Préparation
L'adresse de l'opérateur 0x7C8601d4645b93cea45F71e118A729332e6B5CA0 a été financée via trois retraits Tornado Cash à partir du 28 octobre. Le 29 octobre, il a répété le processus complet « délégation—balayage » sur trois portefeuilles qu'il possédait, ne transférant que de 2 à 6 $ à chaque fois ; à 15h59 ce jour-là, il a déployé le contrat de balayage 0x63e842B054Bd624a465454D533C33F573e9c6fAe qui serait ensuite utilisé contre Binance. Le contrat n'est pas vérifié, liste l'opérateur comme seul appelant autorisé, et contient une fonction de balayage (transférant tous les jetons listés et l'ETH du compte vers un destinataire spécifié) et une fonction de transfert (permettant au compte délégué d'appeler d'autres contrats).
2. Pulvérisation de nonces : 50 autorisations, un coup au but
À 20:20:59, l'opérateur a envoyé une transaction de type 4 à Binance 14 (0x28C6c06298d514Db089934071355E5743bf21d60), portant 50 autorisations EIP-7702 signées avec la clé privée de Binance 14, une pour chaque nonce de 18 914 775 à 18 914 824, chacune déléguant le portefeuille au contrat de balayage. À ce moment-là, Binance 14 traitait encore des retraits clients, et l'attaquant ne pouvait pas savoir quel nonce était actuellement valide, il a donc simplement signé toute une fenêtre. 49 étaient invalides, 1 a touché, et la délégation a pris effet immédiatement—tandis que les propres transactions de Binance continuaient d'être envoyées depuis le même portefeuille comme d'habitude.
3. Balayage : une transaction prend 2,5 milliards de dollars
À 20:24:23, trois minutes et vingt-quatre secondes plus tard, l'opérateur a appelé sweep sur Binance 14, transférant 167 464 ETH, 1,615 milliard d'USDT et environ 60 autres jetons vers une adresse de réception auparavant sans historique 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c. Binance 14 s'est retrouvé avec seulement 1 ETH. Aux prix de l'époque, ce panier d'actifs valait environ 2,5 milliards de dollars.
4. Dix autres clés privées sur quatre chaînes
24 secondes après le balayage, Binance 16 a envoyé 28 005,6 ETH, 55,7 millions d'USDT, 25,9 millions de RLUSD, 84,5 WBTC et cinq autres jetons à la même adresse. En 12 minutes, Binance 55 sur Optimism a envoyé 44,2 millions d'OP, quatre portefeuilles chauds sur Arbitrum ont envoyé 74,6 millions d'ARB et 8 426 ETH, et quatre portefeuilles chauds sur Avalanche ont envoyé 1,81 million d'AVAX et 8,41 millions d'USDT.
Aucun de ces portefeuilles n'avait de code. Chaque transfert était une transaction ordinaire signée avec la clé privée du portefeuille lui-même, envoyée au milieu de retraits routiniers. Les statistiques publiques attribuent également 18 270 BTC sur la chaîne Bitcoin et environ 630 millions de dollars sur la chaîne Tron au même acteur (cette partie est marquée dans l'original comme en attente de confirmation du renseignement sur les menaces ; voir la note du traducteur).
5. Compte intelligent et drainage continu
À 20:41:23, l'opérateur a utilisé Binance 14 toujours délégué—qui détenait un compte intelligent Circle, Binance Hot Wallet 34—pour transférer 780 millions d'USDC de ce compte vers l'adresse de réception, suivi de 43 millions d'USDC supplémentaires. À 21:44, il a de nouveau balayé Binance 14, prenant 200 millions d'USDT et 13 autres jetons arrivés après le premier balayage. À 22:00, la délégation était toujours effective, et tout fonds envoyé à Binance 14 pouvait être pris sans autre signature.
Pourquoi la surveillance onchain et l'exposition au risque comptent tout autant lorsque les fonds volés circulent
Les institutions peuvent contrôler leurs propres clés et processus de signature, mais elles ne peuvent pas contrôler les plateformes par lesquelles les fonds circulent, les contreparties qui leur déposent de l'argent, ni l'attaquant qui a déjà déplacé 3 milliards de dollars sur quatre chaînes. C'est précisément cette surface de risque externe qui relève du périmètre de la surveillance onchain et de l'exposition au risque ; et dans cet incident, les deux ont commencé à fonctionner dans les secondes suivant le premier transfert.
La surveillance on-chain détecte des comportements, pas des signatures. Les signaux dans cet incident étaient : le code d'un hot wallet est passé de vide à un pointeur de délégation ; une adresse de vault a déplacé un montant de la taille d'un inventaire vers une adresse sans historique ; la même nouvelle adresse a reçu des fonds de 11 portefeuilles signalés sur quatre chaînes en 12 minutes. Aucun de ces éléments ne nécessite un schéma d'attaque connu ou une vulnérabilité de contrat, de sorte que les détecteurs de Blockaid se sont déclenchés 1 minute 55 secondes après le balayage, et en 7 secondes pour chaque transfert cross-chain. La délégation elle-même est restée visible on-chain pendant 3 minutes 24 secondes—toute institution surveillant les changements d'état de sa propre adresse disposait de cette fenêtre pour agir. Lorsque l'alerte de surveillance se déclenche, le workflow de réponse de Blockaid peut pousser une transaction « balayer le solde » ou « effacer la délégation » directement dans la plateforme de custody de l'institution, la réponse et la détection commençant dans la même minute.
Risk Exposure traite l'autre face du même incident : tous ceux qui sont sur le point de recevoir cet argent. Dans les 90 minutes suivant le balayage, les fonds volés ont touché Permit2, LI.FI, Uniswap, UniswapX et Aave, puis des ponts cross-chain et des échanges d'agrégateurs. Chaque pool, marché de prêt, pont cross-chain, teneur de marché et exchange sur ce chemin détient ou a traité ces fonds volés, et le risque de conformité leur incombe dès l'arrivée des fonds. Risk Exposure fournit à ces institutions des signaux en temps réel.
Comment EIP-7702 transforme une clé privée divulguée en contrôle permanent
Avant EIP-7702, une clé privée de hot wallet volée signifiait une course contre la montre : l'attaquant devait compléter chaque signature avant que l'autre partie puisse déplacer le solde, et une fois que l'exchange avait basculé vers une nouvelle adresse, la clé privée était sans valeur. Une clé privée capable de signer des délégations change cela.
Une autorisation, valable à un seul nonce, a transformé Binance 14 en un programme détenu par l'attaquant. Le premier balayage a pris le solde à 20:24 UTC, et la délégation est restée en place sans être touchée ; à 21:44 UTC, l'attaquant a pris plus de 200 millions de dollars de nouveaux dépôts sans que le portefeuille signe une autre transaction. Basculer vers une nouvelle clé privée ne la supprime pas, car la délégation appartient à l'adresse, pas à la clé privée. Seule la signature d'une autre autorisation avec la clé privée divulguée qui pointe le compte vers l'adresse zéro peut la réinitialiser ; jusque-là, chaque fonds envoyé à Binance 14 est accessible.
Pour les équipes gérant de grands EOA, les étapes actionnables sont concrètes : traiter les autorisations EIP-7702 comme des opérations privilégiées et les gérer selon la même politique que les transferts de cold wallet ; surveiller les changements de code sur chaque adresse de hot wallet et préparer à l'avance les transactions de révocation ; ne pas conserver d'inventaire sur une adresse dont le statut de délégation est incertain ; après une fuite, effacer d'abord la délégation, puis faire tourner les clés et recharger le portefeuille ; et sur chaque transaction de délégation, transmettre la liste d'autorisations à la couche de filtrage—car dépouillée de cette liste, une délégation ressemble à un appel vide vers une adresse de confiance. Le moteur de Blockaid évalue déjà cette liste, et Cosigner la transmet déjà ; la lacune révélée par cet incident réside dans les flux de signature qui ne le font pas.
Conclusion
Les fuites de clés privées restent la plus grande source de pertes on-chain. Si les estimations publiques se confirment, il s'agira du plus grand vol de l'histoire, plus de trois fois le montant d'environ 1,5 milliard de dollars volé à Bybit en février 2025. Les clés privées de 11 hot wallets Binance ont signé des transferts vers une adresse créée quelques minutes plus tôt, et l'une d'elles a également signé une autorisation EIP-7702, transformant son portefeuille en infrastructure permanente de l'attaquant. Les émetteurs de stablecoins ont gelé environ 2,4 milliards de dollars en deux heures, tandis que les actifs natifs tels que l'ETH restent entre les mains de l'attaquant.
Une signature valide produite par une clé privée divulguée ne semble pas différente on-chain d'une signature légitime. Le succès ou l'échec de ce type d'attaque se décide au moment de la signature par la politique—une politique qui vérifie ce que cette clé privée est sur le point de signer ; et dans les minutes qui suivent, par la surveillance—le suivi des fonds qui peuvent encore être interceptés.
