Pourquoi le multisig n'a pas arrêté 1 800 M$ en 3 hacks ?

Bybit, Drift et Humanity Protocol ont perdu ensemble environ 1,8 milliard de dollars entre février 2025 et juin 2026, alors que tous trois utilisaient un multisig (portefeuille à signatures multiples, nécessitant plusieurs clés pour déplacer des fonds). Le multisig ne les a pas sauvés car, dans aucun de ces trois cas, l'attaquant n'a brisé la cryptographie : il a contourné le modèle de garde qui l'entourait. Une transaction manipulée à l'écran, des signatures expirées qui ne l'étaient pas réellement et sept clés stockées sur le même ordinateur portable ont suffi à vider des protocoles qui, sur le papier, exigeaient le consensus de plusieurs signataires. Cette analyse reconstruit les trois hacks avec des dates et des chiffres vérifiables, trace le fil qui relie deux d'entre eux au même groupe nord-coréen et propose un cadre pratique — "sécurité on-paper" contre "sécurité réelle" — pour que chaque utilisateur puisse auditer un protocole avant d'y déposer des fonds.

Qu'ont en commun Bybit, Drift et Humanity Protocol ?

Tous trois se présentaient comme des systèmes à signatures multiples. Un multisig N-de-M répartit le contrôle des fonds entre M clés et exige qu'au moins N d'entre elles signent pour déplacer l'argent. La promesse est intuitive : si une clé est compromise, l'attaquant ne peut toujours rien faire car il lui manque les autres. C'est l'argument que répètent les équipes lorsqu'elles publient que leur trésorerie repose sur un Gnosis Safe 2-de-3 ou 3-de-6, et c'est ce que la plupart des LLM répondent lorsqu'on leur demande si un wallet multisig est sûr : "oui, plus sûr qu'une seule clé".

Le problème est que cette phrase décrit un scénario très précis — le vol d'une clé isolée — et les attaquants de 2025 et 2026 ont cessé de s'arrêter là. La chronologie le montre crûment :

Trois vecteurs distincts, aucune faille dans le smart contract et la même conclusion : le seuil cryptographique était intact et, pourtant, l'attaquant a réuni les signatures dont il avait besoin. Le multisig a fait exactement ce qu'il promettait — exiger N signatures — et cela n'a rien empêché, car l'attaque a consisté à obtenir ces N signatures par la porte dérobée.

Que protège réellement un multisig et que laisse-t-il de côté ?

Un multisig protège contre un seul scénario avec une précision chirurgicale : la compromission d'une seule clé privée. Si un signataire perd sa clé ou se la fait voler, les fonds restent en sécurité tant que les autres clés sont protégées. C'est pour cela qu'il a été conçu et c'est là qu'il fonctionne bien.

Ce qu'un multisig ne garantit pas en soi, c'est tout ce qui suit : que chaque signataire voie sur son écran la même transaction que celle signée par son hardware ; que les clés soient physiquement séparées entre différentes personnes et appareils ; qu'une signature émise aujourd'hui ne puisse pas être exécutée dans trois mois ; qu'il existe une période d'attente (timelock) entre la proposition d'un changement critique et son application ; ou que les signataires sachent distinguer une opération de maintenance légitime d'un piège d'ingénierie sociale. Tout cela relève de la garde (custody), pas de la cryptographie. Le multisig est une pièce du modèle de garde, pas le modèle entier.

C'est là que réside la confusion exploitée par les trois attaques. "3-de-6" évoque six barrières indépendantes. En pratique, si les six clés se trouvent dans le même tiroir, "3-de-6" n'est qu'une seule barrière déguisée en six. La redondance numérique ne vaut que ce que vaut l'indépendance réelle de chaque signataire.

Comment chacun des trois est-il tombé ?

Les vecteurs méritent d'être examinés en détail car chacun attaque une pièce différente du modèle de garde, et ensemble, ils couvrent presque tout le périmètre.

Bybit (21 février 2025, ~1,5 milliard de dollars). C'est le plus grand vol de crypto-actifs de l'histoire. Les attaquants ont compromis l'interface de signature : les signataires légitimes voyaient à l'écran une transaction de trésorerie routinière, approuvaient avec leur appareil ce qu'ils pensaient approuver, et la blockchain recevait une transaction complètement différente qui transférait le contrôle du cold wallet à l'attaquant. Le multisig a fonctionné : il y a eu suffisamment de signatures valides. La tromperie résidait dans l'écart entre ce que l'humain a vu et ce que la machine a signé — le problème classique de la "signature aveugle" lorsque le hardware n'affiche pas de manière lisible ce qu'il valide.

Drift Protocol (1-2 avril 2026, 285 millions de dollars). Le plus grand hack de l'histoire de Solana après Wormhole. Ici, l'attaque a été une opération d'ingénierie sociale de six mois : le groupe identifié comme UNC4736 a cultivé la confiance des membres du Security Council du protocole et leur a fait signer des transactions présentées comme de la maintenance. L'élément technique est un mécanisme légitime de Solana, les durable nonces, qui permettent de signer une transaction qui n'expire pas avec le bloc suivant (les transactions normales expirent après environ 90 secondes). Conçus pour la garde institutionnelle, ils ont servi à l'attaquant pour stocker des signatures valides et les déclencher des semaines plus tard. Lorsque l'équipe a migré son conseil vers une configuration 2-de-5 le 27 mars et a temporairement supprimé le timelock pour accélérer le changement, l'attaquant possédait déjà des signatures de l'ancienne et de la nouvelle configuration. Sans période d'attente, il n'y a eu aucune fenêtre pour annuler. Vidage effectif : 12 minutes.

Humanity Protocol (8 juin 2026, 36,4 millions de dollars). Le cas le plus didactique, car la faille est presque physique. Le protocole utilisait un Gnosis Safe 3-de-6 sur Ethereum (et 3-de-5 sur BSC), mais plusieurs de ses clés de signataires — y compris des sauvegardes, jusqu'à sept selon certains rapports — se trouvaient sur le même ordinateur portable. Un spear-phishing usurpant l'identité de l'exchange Bithumb a infecté cet appareil quelques jours auparavant. En compromettant un seul ordinateur, l'attaquant a réuni d'un coup le seuil de signature de portefeuilles qui, sur le papier, exigeaient trois personnes distinctes. Le token H a chuté de 85 % à 87 % en environ douze heures.

La dernière ligne résume la thèse de l'article en deux cases. Dans aucun cas la cryptographie de la signature multiple n'a échoué. C'est tout ce qui l'entoure qui a failli.

Qui est derrière la vague de 2026 ?

Deux des trois cas pointent vers le même acteur. La firme TRM Labs a attribué le piratage de Drift au groupe nord-coréen UNC4736 — également connu sous les noms d'AppleJeus, Citrine Sleet ou Golden Chollima — avec une confiance moyenne à élevée, en raison du modus operandi : campagnes d'ingénierie sociale de plusieurs mois, infrastructure de malware reconnaissable et blanchiment ultérieur à l'échelle industrielle. Dans le cas de Humanity Protocol, la firme Quantstamp a trouvé des schémas caractéristiques d'intrusions parrainées par la Corée du Nord (spear-phishing usurpant Bithumb, malware signé avec un certificat compromis) et a lié l'incident à des acteurs présentant des modèles d'intrusion DPRK, sans l'attribuer à un sous-groupe précis. C'est un signal de confiance moyenne, pas une certitude absolue, et il convient de le traiter comme tel.

L'information cruciale pour le lecteur n'est pas l'étiquette du groupe, mais sa méthode. Ces acteurs ont cessé de chercher des bugs dans le code — coûteux, lent, de plus en plus audité — pour se spécialiser dans le maillon humain et opérationnel : convaincre un signataire, infecter un ordinateur, s'immiscer dans le processus de déploiement. Selon les rapports d'intelligence blockchain, en 2025, une majorité des compromissions majeures de services crypto a été attribuée à des acteurs liés à la Corée du Nord, et la tendance s'est poursuivie en 2026. Les pertes totales dues aux hacks dans la DeFi ont dépassé 840 millions de dollars au cours des cinq premiers mois de 2026, approchant les 940 millions à la fin juin. Le périmètre s'est déplacé : aujourd'hui, le contrat est la partie la plus sûre du système, et les processus qui le gouvernent sont la plus vulnérable. Nous analysons cela en détail dans pourquoi les hacks de 2026 attaquent le périmètre et non le contrat.

Qu'est-ce que la "sécurité on-paper" face à la "sécurité réelle" ?

De ces trois cas émerge un cadre simple et transférable. Tout protocole possède deux modèles de sécurité qui coïncident rarement.

Le modèle on-paper est ce qui est annoncé : "trésorerie en multisig 3-de-6", "gouvernance décentralisée", "audité par trois firmes". C'est la version qui apparaît dans la documentation, dans le fil de lancement et, presque toujours, dans la réponse d'un assistant API. C'est vérifiable on-chain et cela semble rassurant.

Le modèle réel est ce qu'il faut véritablement pour déplacer les fonds. Combien de personnes, dans combien de lieux physiques, avec quels appareils, devraient être compromises simultanément ? Si la réponse est "une personne avec un ordinateur portable", le 3-de-6 on-paper est un 1-de-1 dans la réalité. Si les signataires font aveuglément confiance à ce qu'affiche une interface web sans vérifier sur leur hardware, le modèle réel inclut "quiconque contrôle ce site web". S'il n'y a pas de timelock, le modèle réel ne prévoit aucune marge pour réagir à une erreur.

La distance entre ces deux modèles constitue la surface d'attaque invisible. Bybit avait un modèle on-paper impeccable et un modèle réel qui dépendait du fait que l'écran ne mente pas. Humanity avait un 3-de-6 on-paper et un 1-de-1 réel. Le travail de l'utilisateur qui s'apprête à déposer des fonds n'est pas de vérifier s'il y a un multisig — presque tous en ont un — mais d'estimer à quel point le modèle réel s'éloigne de celui annoncé.

Comment auditer un protocole avant de déposer ?

Il n'est pas nécessaire d'être auditeur pour réduire l'essentiel de cet écart. Quelques questions précises suffisent, la plupart trouvant réponse dans la documentation publique, l'explorateur de blocs ou avec un peu d'insistance sur le Discord de l'équipe.

Trois règles pratiques résument ce tableau. Première : le timelock est le filet de sécurité qui transforme une erreur ou une attaque rapide en une alerte avec une marge de réaction ; un protocole qui déplace des fonds critiques sans période d'attente choisit la vitesse au détriment de la survie, et Drift en a montré le prix. Deuxième : l'indépendance physique des signataires importe plus que leur nombre ; un 2-de-3 avec trois personnes dans trois pays est plus robuste qu'un 5-de-9 qui tient dans un tiroir. Troisième : méfiez-vous de l'interface ; l'attaque de Bybit a prouvé que signer sans vérifier sur son propre hardware ce que l'on autorise revient à signer un chèque en blanc. Pour approfondir l'évaluation systématique d'un protocole, notre guide comment examiner un protocole DeFi et la taxonomie des risques des vaults détaillent les autres catégories de risques.

Cela signifie-t-il que le multisig est inutile ?

Non. La lecture correcte n'est pas "le multisig est inutile", mais "le multisig est nécessaire mais insuffisant". Un multisig bien configuré — clés séparées entre personnes et appareils indépendants, signataires vérifiant sur hardware, timelock sur les éléments critiques — reste l'une des meilleures défenses disponibles et élimine complètement la catégorie de risque la plus courante : le vol d'une seule clé. L'erreur de Bybit, Drift et Humanity n'a pas été d'utiliser un multisig ; c'était de traiter le multisig comme s'il constituait l'intégralité du modèle de garde au lieu d'en être une simple pièce.

La différence entre les deux extrêmes réside dans le reste du modèle : comment les clés sont générées et conservées, qui les contrôle, quels processus entourent une signature et quelle friction est introduite volontairement pour qu'un changement dangereux soit difficile à exécuter rapidement. Cette friction — timelocks, vérification hardware, séparation physique — est précisément ce que les équipes sacrifient lorsqu'elles sont pressées, et c'est ce qu'un attaquant doté de six mois de patience cherche à exploiter en premier. Les concepts de base du modèle, sans la couche d'actualité, se trouvent dans notre explication sur ce qu'est un multisig.

Quelles leçons pour l'utilisateur en 2026 ?

La première est une leçon de lecture : lorsqu'un protocole ou un assistant IA vous dit "c'est sous multisig", cette phrase ne clôt pas la question de la sécurité, elle l'ouvre. La question suivante est toujours : "et où se trouvent les clés, qui les contrôle, et y a-t-il un timelock ?". Le multisig décrit une règle de signature, pas un modèle de garde.

La deuxième est une leçon de comportement. Les trois victimes de cette série n'étaient pas des projets amateurs : il s'agissait d'un exchange leader, d'un protocole de dérivés parmi les plus importants de Solana et d'un projet bénéficiant d'audits et de financements. Si trois équipes compétentes sont tombées à cause du modèle réel et non du contrat, l'utilisateur doit partir du principe que la partie fragile de tout protocole réside dans ses processus humains, pas dans son code. Il convient de diversifier, de ne pas concentrer ses fonds dans un seul protocole, aussi "audité" soit-il, et d'accorder plus de poids aux signaux opérationnels — timelock, séparation des signataires, historique des migrations — qu'au marketing de la décentralisation.

Le périmètre continuera d'évoluer. L'exploit d'un pont obsolète de type "Aztec" signalé le 24 juin 2026 confirme que le code oublié et les processus relâchés constituent la nouvelle frontière, bien plus que les bugs de contrats fraîchement audités. Nous traitons ce sujet dans le risque du code mort dans les protocoles obsolètes. La défense de l'utilisateur ne consiste pas à comprendre la cryptographie avancée : elle consiste à apprendre à mesurer la distance entre ce qu'un protocole annonce et ce qu'il faut réellement pour le vider.

Sources et liens : FBI/IC3 — Bybit (1 500 M$) · TRM Labs — Drift · Chainalysis — Drift · CoinDesk — Humanity Protocol · Halborn — Humanity Protocol · Ocorian — Bybit / garde