Piratage Binance 2026 : retraits, réserves et causes

Peut-on de nouveau effectuer des retraits sur Binance ?

Le 5 novembre, Binance a annoncé de nouvelles réouvertures progressives à partir de 04:00 UTC. Chaque paire jeton–réseau doit être vérifiée dans le service officiel.

Le 4 novembre, Binance a déclaré avoir reconstitué environ 98 % du montant concerné avec ses ressources. Ce n’est pas un taux de restitution des actifs volés.

Le relevé des réserves du 4 novembre à 00:00 UTC couvre 44 jetons selon Binance. Sa preuve cryptographique complète était encore en cours à l’annonce. Ce relevé n’est ni un audit financier complet ni une preuve des causes. [28] [29] [17]

Gelé ne signifie pas remboursé

L’ancien montant de 2,54 milliards de dollars était un état provisoire. Binance annonce désormais près de 3 milliards gelés. Un gel peut limiter le déplacement de certains jetons ; il ne signifie pas que ces actifs ont déjà été restitués à Binance ou aux utilisateurs.

L’impact total estimé à environ 6,3 milliards ne représente pas non plus une perte nette définitive. Ces chiffres d’une enquête en cours décrivent des grandeurs différentes. Soustraire 3 de 6,3 milliards ne permet donc pas d’établir un déficit de couverture confirmé ou une perte finale. [11] [14] [15]

Plusieurs points de compromission, au-delà d’un seul ordinateur

La première explication de Binance décrivait un ordinateur DevOps compromis et l’accès à un conteneur de service. La version ultérieure évoque d’autres points de compromission. Richard Teng affirme que plusieurs machines ou permissions étaient en jeu. Cette première piste ne constitue donc pas encore une cause entièrement reconstituée.

Selon Teng, la délégation EIP-7702 n’est pas passée par les contrôles d’approbation habituels. La question devient précise : quel chemin a permis cette autorisation alors que les contrôles normaux auraient dû l’examiner ? La déclaration ne publie pas l’ensemble des journaux, identités et contournements techniques. Elle ne prouve ni une méthode précise d’hameçonnage ni une évasion de conteneur.

La délégation observée sur Ethereum et l’accès à l’infrastructure opérationnelle sont deux niveaux différents. La blockchain montre les autorisations et transactions traitées ; l’enquête opérationnelle doit expliquer l’accès en amont. EIP-7702 permet une délégation de code. Ce n’est pas une règle de multisignature, quelle que soit la simplification utilisée dans un entretien. [5] [14] [22] [23]

Que faire ?

Vérifiez l'état du service dans l'application Binance habituelle ou en saisissant vous-même l'adresse officielle. Ignorez les liens inattendus proposant un remboursement ou un déblocage ; ne communiquez jamais mot de passe, code à usage unique ou phrase de récupération. Les entreprises peuvent vérifier les responsables, les procédures d'approbation et la communication de crise, puis documenter les soldes et transactions par les canaux officiels. Évitez toute opération précipitée fondée sur une rumeur. [6]

Pourquoi un ordinateur compromis ne prouve pas un vol de clés

Un attaquant n’a pas toujours besoin d’emporter une clé privée sous forme de fichier pour déclencher une transaction illicite. Dans une infrastructure dotée de services de signature, la question peut être celle des demandes qui atteignent le signataire protégé. Détourner ce chemin peut produire des signatures valides pour une opération non approuvée. C’est une analyse technique, pas un nouveau fait établi chez Binance.

Binance n’annonce actuellement aucun indice de fuite de clés privées de portefeuille. Il devient donc essentiel d’examiner identités, accès aux conteneurs et règles d’approbation. La question reste ouverte : un premier constat de l’entreprise ne remplace ni la reconstitution complète ni une vérification indépendante. Cause, bilan des actifs et remboursements éventuels nécessitent des preuves distinctes. [5] [14] [16]

EIP-7702 : ce qu’une autorisation permet réellement

EIP-7702 est une fonction d’Ethereum permettant à un compte de déléguer l’exécution de code à un contrat intelligent. Une autorisation valide du compte est nécessaire. Un tiers peut inclure cette autorisation dans une transaction adaptée et payer les frais : la transaction extérieure ne doit pas nécessairement provenir du compte délégant.

Une fois l’autorisation acceptée, le compte pointe vers le code choisi. Un appel ultérieur peut exécuter ce code dans le contexte du compte et agir sur ses actifs. La délégation reste en place jusqu’à ce qu’une nouvelle autorisation valide la modifie ou l’annule. EIP-7702 est une fonction ; aucune faille de cette norme n’a été établie comme cause de cet incident.

Le code peut être appelé dans la phase d’exécution de la même transaction ; un appel ultérieur n’est pas obligatoire. Une autorisation cryptographiquement valide ne prouve pas que l’organisation souhaitait cette action. Un échec (« revert ») dans la phase d’exécution suivante n’annule pas la délégation déjà inscrite. [5]

Ce que montre l’analyse initiale de la blockchain

La société de sécurité Blockaid rapporte une transaction contenant 50 autorisations EIP-7702 pour l’adresse étiquetée Binance 14. Une autorisation aurait été acceptée, déléguant le compte à un contrat. Le nonce d’une autorisation doit correspondre au compteur actuel du compte. Il s’agit d’une analyse externe préliminaire, pas d’un rapport d’enquête final de Binance.

Une analyse indépendante de 808bits situe la délégation au 29 octobre à 20 h 20 min 59 s UTC et un appel ultérieur impliquant des mouvements de jetons et d’ether à 20 h 24 min 23 s UTC. Ces heures concernent les transactions Ethereum examinées, pas tous les réseaux ni une perte totale définitive. Une autorisation valide ne révèle pas comment elle a été produite : vol de clé, usage abusif du processus de signature ou autre accès ne sont pas établis par ces seules observations.

Sources : 808bits et drk.vc. Ces heures décrivent des transactions examinées, pas une perte totale confirmée. [4] [7] [8]

Faites défiler le tableau horizontalement.

Contrôles possibles du processus de signature

Pour les services de conservation et les infrastructures de portefeuille, la question centrale est ce qu’une signature autorise réellement. Les systèmes de signature et d’approbation devraient afficher clairement le type de demande, le réseau, le contrat cible et le nonce, puis les comparer à une politique documentée. Dans la mesure du possible, éviter les approbations aveugles de condensats inconnus et les délégations inutiles.

Les équipes peuvent limiter les destinations autorisées, alerter sur les changements et séries inhabituelles d’autorisations et soumettre les changements critiques à une vérification indépendante. Un plan d’arrêt et de reprise testé, des responsables identifiés et la conservation des journaux facilitent l’enquête. Rien ne prouve encore qu’une de ces mesures aurait empêché cet incident précis.

Ces contrôles constituent une analyse technique de Cyberkern. Les règles doivent vérifier le contenu réellement signé avant signature ; approuver un simple condensat peut en masquer l’objet. Une alerte sur chaîne après exécution arrive trop tard pour empêcher cette transaction. Une adresse autorisée ne garantit pas à elle seule un code sûr. [5] [9]

Ce que révèlent les 50 autorisations et le nonce

Le nombre 50 décrit d’abord les entrées d’une liste d’autorisations. Il ne correspond ni au nombre de clients touchés ni à la preuve de 50 clés volées. Ethereum vérifie notamment la signature, le réseau et le nonce du compte pour chaque entrée. Une entrée non conforme est ignorée et le traitement de la liste continue.

Le nonce est un compteur de compte. Sur un portefeuille très actif, il peut évoluer rapidement avec les transactions. Plusieurs autorisations portant des valeurs différentes peuvent ainsi couvrir une fenêtre mouvante. Les analyses externes rapportent une autorisation acceptée dans la transaction Binance étudiée. Ce constat n’est pas une limite du protocole : une liste peut contenir plusieurs entrées valides et chaque autorisation acceptée incrémente le compteur. [5] [7] [12]

Comment cela peut-il arriver malgré la protection des signatures ?

La première piste DevOps n’explique pas toute la séquence. Richard Teng identifie d’autres points de compromission et affirme que la délégation n’a pas traversé les contrôles habituels. L’examen annoncé couvre terminaux, cloud, gestion des clés et signatures. Les opérateurs doivent donc vérifier chaque chemin d’autorisation critique, en plus de protéger les appareils.

Trois questions de contrôle en découlent pour les opérateurs. Elles relèvent de l’analyse technique de Cyberkern ; la déclaration préliminaire ne permet pas d’affirmer qu’un contrôle précis aurait certainement empêché l’incident :

Une reconstitution fiable relie journaux d’accès, activité du conteneur, demandes de retrait, validations et signatures. Sur la blockchain, il faut distinguer la révocation annoncée de l’état historique. Une simple action sur un compte ou une session ne prouve pas qu’une délégation antérieure a été effacée sur chaîne. [5] [12] [14] [22] [23]

• Identité et demande : quelle identité pouvait envoyer des demandes critiques depuis l’appareil touché ? Affichage et contenu réellement signé ont-ils été comparés indépendamment ?
• Droits du conteneur : quels services et fonctions de retrait étaient accessibles ? Permissions, accès aux services et dérogations étaient-ils limités au nécessaire ?
• Endiguement et preuves : quand les accès ont-ils été bloqués, les autorisations révoquées et les changements vérifiés dans les journaux ou l’état de la blockchain ?

Un portefeuille matériel ou hors ligne aurait-il suffi ?

Des clés conservées hors ligne et du matériel adapté peuvent réduire fortement l’exposition au vol de clés. Cette protection compte. Elle ne remplace toutefois pas la vérification de l’action : une clé bien protégée peut signer une demande dangereuse si une mauvaise délégation ou destination est approuvée.

Une plateforme d’échange doit aussi conserver des fonds opérationnels et traiter des retraits fréquents. Limiter les soldes des portefeuilles connectés, séparer les responsabilités et imposer des règles claires pour les signatures critiques sont donc des protections complémentaires. Les sources examinées ne documentent pas entièrement le matériel, le partage des clés ou la conservation hors ligne de Binance dans les systèmes concernés. Cet incident ne prouve ni l’inutilité des portefeuilles matériels ni qu’un produit précis l’aurait certainement empêché. [5] [13]

Trois questions pour les utilisateurs et le rapport d’enquête

Mon propre portefeuille est-il compromis ? Un incident chez Binance ne démontre pas un accès à un portefeuille personnel géré indépendamment. Un solde sur une plateforme et des clés détenues en propre sont deux situations différentes. Vérifiez votre compte dans l’application habituelle ou en saisissant vous-même l’adresse officielle ; un article général ne peut établir votre solde individuel.

Faut-il valider une indemnisation ou une réparation du portefeuille ? Non. L’annonce d’un incident ne justifie ni l’approbation d’un contrat inconnu, ni la divulgation d’une phrase de récupération, ni un paiement à une personne proposant son aide. Ces offres peuvent provoquer une nouvelle perte. Les changements techniques sur un portefeuille réellement touché doivent s’inscrire dans un plan de récupération vérifié.

Que doit établir un rapport complet ? Le lien technique et chronologique entre accès, signature et mouvements de fonds, puis un bilan séparant transferts, actifs gelés, restitutions et perte résiduelle. Une promesse de couverture répond à la responsabilité financière ; elle ne remplace ni les preuves de la cause ni celles des remboursements déjà réalisés. Une preuve de réserves seule ne remplace ni un audit financier complet ni l’examen des causes et des contrôles de sécurité internes. [5] [6] [13] [14] [17]