Le 29 octobre 2026, Binance a subi un incident de sécurité grave et hautement sophistiqué. Cela n’aurait pas dû se produire et nous présentons nos excuses pour l’inquiétude, les perturbations et l’incertitude que cela a occasionnées à nos utilisateurs, à nos partenaires et au secteur dans son ensemble.
Notre principale responsabilité est de protéger les utilisateurs. Binance assumera l’impact financier lié aux fonds volés, et non nos utilisateurs. Nous avons déjà réservé plus de 100 % des fonds nécessaires pour couvrir les pertes. Au 31 octobre 2026, 98 % des actifs en tokens concernés avaient été restitués. Vous pouvez le vérifier sur notre page de Preuve de réserves (Proof of Reserves). Nous sommes actuellement en train d’acquérir les actifs restants, dont la liquidité est plus faible.
L’incident a touché environ 6,34 milliards USD d’actifs numériques. À la date de cette mise à jour, environ 2,85 milliards USD d’actifs numériques ont été gelés ou interceptés, sous réserve de rapprochement et de la volatilité des prix du marché.
Nous avons pris des mesures immédiates pour contenir l’incident et renforcer les systèmes concernés. Les points d’accès identifiés comme ayant été utilisés lors de l’attaque ont été fermés. Les systèmes impliqués dans la chaîne d’attaque ont été reconstruits ou remplacés. Nous avons également mis en place des contrôles plus stricts sur les appareils, renforcé les contrôles des risques liés aux services de portefeuille et étendu la détection des anomalies comportementales fondée sur l’intelligence artificielle (IA).
Il s’agit de notre rapport initial. Nous y présentons ce que nous savons à ce jour ainsi que les améliorations déjà mises en œuvre. L’enquête se poursuit et nos conclusions feront l’objet d’un examen indépendant supplémentaire. Certains détails techniques resteront confidentiels afin d’empêcher les acteurs malveillants de s’en servir pour préparer des attaques. Nous collaborons avec des sociétés indépendantes spécialisées dans la sécurité afin de mener un examen complémentaire.
Les informations les plus récentes publiées par le Bureau fédéral d’enquête des États-Unis (FBI) indiquent que la République populaire démocratique de Corée est responsable de cet incident.
Nous partageons ce rapport initial, car la sécurité progresse lorsque le secteur apprend et partage ses connaissances collectivement.
Ce qui s’est passé le 29 octobre
L’attaque s’est rapidement propagée à travers plusieurs réseaux.
L’attaquant a exploité l’accès non autorisé à un service interne de signature de transactions de portefeuilles pour lancer des opérations en dehors du processus habituel de retrait.
Entre 20 h 05 et 20 h 09 UTC, cinq portefeuilles chauds de Binance ont envoyé 233,46 millions de XRP à une adresse contrôlée par l’attaquant.
Les portefeuilles chauds de Binance sur Solana et Optimism ont envoyé environ 970 500 SOL et 44,2 millions d’OP à des adresses contrôlées par l’attaquant.
Par la suite, Binance a reçu une alerte interne concernant des transferts de montants importants et a immédiatement ouvert une enquête.
Un portefeuille chaud de Binance a envoyé 18 270 BTC à une adresse contrôlée par l’attaquant.
L’attaquant a ensuite utilisé le service de signature pour exploiter le mécanisme d’autorisation EIP-7702 d’Ethereum. EIP-7702 permet à un compte de déléguer certains droits d’exécution à un contrat intelligent sans exposer sa clé privée. Dans ce cas, l’attaquant s’est servi de ce mécanisme pour accorder à un contrat intelligent sous son contrôle des droits d’exécution partiels sur un portefeuille chaud de Binance.
Binance a immédiatement lancé plusieurs mesures de confinement, notamment la suspension des retraits afin de limiter les nouvelles sorties de fonds, la coordination avec des partenaires pour geler les jetons concernés et la mise en œuvre de mesures visant à révoquer les autorisations non autorisées. Ces efforts ont permis de geler au total 2,85 milliards USD d’actifs.
Cependant, la suspension des retraits à elle seule ne pouvait pas empêcher tous les mouvements d’actifs non autorisés. Les autorisations EIP-7702 malveillantes existaient déjà sur la chaîne de blocs (on-chain) et fonctionnaient indépendamment de l’infrastructure habituelle de retrait de Binance.
Les attaquants ont envoyé 50 transactions de signature pour manipuler le nonce du compte et mettre en place des autorisations de délégation malveillantes. Une fois établies, ces autorisations leur ont permis de continuer à transférer des actifs indépendamment de l’infrastructure habituelle de retrait de Binance. Binance a donc dû exécuter des transactions supplémentaires afin de révoquer ces autorisations sur la chaîne de blocs.
Le processus de confinement a comporté des difficultés techniques supplémentaires. Comme le portefeuille chaud utilisait le calcul multipartite (MPC), il n’existait pas de clé privée unique permettant de révoquer immédiatement les autorisations EIP-7702 malveillantes. L’équipe a donc élaboré et exécuté une procédure spécialisée pour révoquer ces autorisations, ce qui a nécessité du temps supplémentaire. En outre, la suspension des retraits et la fermeture des services de portefeuilles chauds n’invalidaient pas automatiquement les autorisations déjà présentes sur la chaîne de blocs.
Ces difficultés ont prolongé le délai nécessaire pour contenir complètement les mouvements d’actifs non autorisés. Nous examinons le processus de réponse à l’incident, la couverture des politiques de signature et les contrôles des portefeuilles chauds, tout en cherchant des moyens de renforcer notre capacité à répondre rapidement aux menaces futures.
Le dernier transfert non autorisé, d’un montant total de 2 961,9 ETH, a été confirmé sur la chaîne de blocs à 23 h 56 UTC. La transaction avait été transmise auparavant et était restée en attente avant d’être confirmée. Aucun autre transfert non autorisé n’a été observé après cette opération.
À 00 h 10 UTC le 30 octobre 2026, Binance a exécuté une nouvelle autorisation depuis le portefeuille chaud Binance14 vers l’adresse zéro, supprimant ainsi le code de délégation EIP-7702.
Préparation de l’attaque
Notre enquête actuelle indique qu’il s’agissait d’une campagne sophistiquée en plusieurs étapes. Il ne s’agissait ni d’une intrusion isolée ni d’un simple incident d’hameçonnage (phishing). Les attaquants ont combiné diverses techniques, notamment l’ingénierie sociale au moyen de faux entretiens d’embauche, le téléchargement de logiciels malveillants, la compromission d’outils d’IA internes, la compromission d’appareils et une méthode avancée d’autorisation de transactions.
Juin 2026 : attaque de la chaîne d’approvisionnement logicielle
L’ingénieur A, de l’équipe DevOps des portefeuilles, a téléchargé une installation modifiée de Homebrew pour installer un outil de programmation populaire basé sur l’IA, après l’avoir recherché sur un moteur de recherche.
Notre équipe de sécurité a détecté l’anomalie, remplacé l’appareil et renouvelé toutes les informations d’identification concernées par mesure de précaution. Cependant, le poste de travail de l’ingénieur A et ceux de ses collègues associés à l’équipe d’infrastructure des portefeuilles ont été exposés à l’attaquant.
En 2026, l’équipe de sécurité de Binance a détecté et déjoué 57 cybermenaces potentielles liées à la Corée du Nord. Ces tentatives illustrent la menace persistante que représentent les acteurs soutenus par des États pour le secteur des cryptomonnaies.
Parmi les techniques utilisées figuraient de faux entretiens d’embauche, des logiciels malveillants déguisés en outils populaires pour développeurs, des progiciels et des extensions de navigateur compromis, de fausses applications de visioconférence et des campagnes d’ingénierie sociale conçues pour voler des identifiants ou installer des programmes malveillants d’accès à distance.
Septembre 2026 : ingénierie sociale
L’ingénieur logiciel B a été contacté sur une plateforme légitime de recherche d’emploi par une personne se faisant passer pour un chef de projet. L’ingénieur B avait un profil sur cette plateforme, dans lequel il mentionnait son expérience chez Binance.
Le prétendu chef de projet a organisé un premier entretien avec un représentant des ressources humaines, suivi d’un deuxième entretien avec une personne qui affirmait être le directeur général d’une entreprise fictive.
Lors du premier entretien, le prétendu représentant des ressources humaines a passé un appel vidéo en direct avec l’ingénieur logiciel B. Afin d’instaurer un climat de confiance, l’intervieweur lui a montré un compte sur les réseaux sociaux contenant des photos et des vidéos personnelles publiées sur la plateforme. Cette méthode était plus élaborée et trompeuse que les techniques d’ingénierie sociale observées auparavant.
Le deuxième entretien s’est déroulé sur une application de messagerie sociale populaire. Vers la fin de l’entretien, l’ingénieur B a reçu pour consigne de télécharger sur son ordinateur professionnel un « test technique » contenant un dépôt de code malveillant. Celui-ci contenait du code malveillant qui s’est exécuté pendant le processus de configuration et a lancé une série d’activités non autorisées.
Le logiciel malveillant employait des techniques sophistiquées d’obfuscation et d’évasion, notamment le remplacement d’un composant légitime d’un outil de développement par une version malveillante afin d’exécuter des commandes et d’établir une communication avec un serveur externe contrôlé par l’attaquant.
Le logiciel malveillant zero-day n’a pas été détecté à ce moment-là par les outils de protection des appareils. L’attaquant a également pris des mesures pour dissimuler l’activité malveillante et effacer les traces de l’intrusion, ce qui a compliqué sa détection ainsi que l’enquête ultérieure.
Le script a exécuté les étapes suivantes au moyen de techniques d’obfuscation destinées à contourner les mécanismes de détection de sécurité :
texte
CREATE /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
MODIFY pyenv_ → 3,414 B
DELETE .../libexec/pyenv (3,344 B)
← supprimer le fichier pyenv légitime
RENAME pyenv_ → pyenv (3,414 B)
← le remplacer par une version malveillante
DELETE /opt/homebrew/bin/pyenv (3,414 B)
ln (créer un nouveau lien symbolique) + spawn zsh
20 octobre 2026 : utilisation d’un outil d’IA interne comme point d’entrée
L’attaquant a exploité l’ordinateur compromis de l’ingénieur B et utilisé un outil d’IA interne pour prendre le contrôle de l’ingénieur A, de l’équipe DevOps des portefeuilles, ainsi que d’un autre ingénieur logiciel des portefeuilles, désigné comme l’ingénieur C.
Peu après, l’attaquant a découvert que l’ingénieur A disposait sur son ordinateur d’un jeton autorisant le déploiement de conteneurs.
29 octobre 2026 : accès aux opérations de signature des portefeuilles
Le 29 octobre, entre 17 h 15 et 19 h 56 UTC, l’attaquant s’est connecté à l’ordinateur de l’ingénieur logiciel C, a utilisé les identifiants volés à l’ingénieur A, de l’équipe DevOps des portefeuilles, a déployé un conteneur et exécuté un script malveillant pour lancer l’attaque.
Mesures mises en œuvre
Au 3 novembre 2026, nous avons mené les actions suivantes :
Nous avons reconstruit le système de portefeuilles concerné dans un nouvel environnement.
Nous avons reconstruit l’outil d’IA interne concerné et renforcé ses contrôles d’accès.
Nous avons remplacé les appareils concernés.
Nous avons désactivé les identifiants et les jetons associés aux ingénieurs concernés.
Nous avons réalisé des analyses de sécurité approfondies sur les appareils de tous les employés.
Nous avons amélioré la détection des anomalies comportementales fondée sur l’IA.
Nous avons renforcé les contrôles des risques liés aux services de portefeuille.
Nous collaborons avec les autorités, les sociétés spécialisées dans l’analyse des chaînes de blocs et nos partenaires du secteur afin de tracer et de geler les actifs concernés.
Nous continuerons à renforcer nos mesures au fur et à mesure de l’avancement de l’enquête. Nous avons mis en place et continuons de mettre en œuvre diverses mesures de sécurité qui resteront confidentielles afin d’empêcher les acteurs malveillants de compromettre nos systèmes.
Prochaines étapes
Nous prenons immédiatement les mesures suivantes :
1. Audit indépendant de cybersécurité
Nous faisons appel à des experts indépendants en cybersécurité pour mener un examen complet de l’incident, valider nos conclusions et recommander des mesures supplémentaires.
La portée et les résultats de cet examen orienteront nos efforts continus de remédiation et d’amélioration.
2. Investissements accrus dans la sécurité et la prévention grâce à l’IA
Nous augmentons nos investissements dans la détection fondée sur l’intelligence artificielle, la protection des appareils, la sécurité des environnements de développement et la surveillance des anomalies comportementales.
3. Fonds de recherche sur la sécurité et initiatives pour le secteur
Nous travaillons à la création d’un fonds de recherche sur la sécurité et à l’élaboration d’initiatives ciblées avec des entreprises leaders dans le domaine de l’IA, des acteurs du secteur et des sociétés spécialisées dans la sécurité, en mettant particulièrement l’accent sur la sécurité de l’IA dans les environnements de chaînes de blocs.
Nous continuerons à communiquer des informations de manière proactive dès qu’elles seront disponibles.