Humanity Protocol : pourquoi un multisig 3-sur-6 n'a pas arrêté 36 M$

Le 8 juin 2026, un attaquant a vidé environ 36,4 millions de dollars de Humanity Protocol en franchissant le seuil de signature de deux portefeuilles multisig parfaitement légitimes. Il n'y a pas eu de bug dans le contrat. Le multisig (portefeuille exigeant plusieurs signatures pour déplacer des fonds) était réel : un Gnosis Safe configuré à 3-sur-6 signatures sur Ethereum et 3-sur-5 sur BNB Chain (BSC). Le problème est que plusieurs de ces clés de signataire — sept au total selon le rapport forensique de l'équipe, incluant les sauvegardes — résidaient sur le même ordinateur portable, celui de Chong Yee Wai, directeur de la Humanity Foundation, infecté quelques jours plus tôt par un e-mail de spear-phishing (attaque de phishing ciblant une personne précise) imitant l'exchange coréen Bithumb. Lorsque le malware a pris le contrôle de cet appareil, il a obtenu le quorum entier. Cet article reconstruit les trois vecteurs de l'attaque, explique pourquoi un 3-sur-6 n'a rien protégé, et quelles leçons de gestion de clés cela laisse pour tout protocole gérant des fonds institutionnels.

Qu'est-ce que Humanity Protocol et pourquoi ce hack est-il important ?

Humanity Protocol est un projet d'identité numérique basé sur la vérification biométrique — scan de la paume de la main — qui s'est vendu comme une alternative à Worldcoin, avec un focus sur l'Asie. Son token, H, s'échangeait autour de 0,70 dollar avant l'incident. Le fondateur, Terence Kwok, a confirmé l'exploit et, dans le même mouvement, a admis une donnée embarrassante pour le projet : sur les environ 9 millions d'identités enregistrées, moins d'un million correspondent à des vérifications biométriques réelles ; le reste est, selon ses mots, majoritairement composé de bots.

L'intérêt de ce cas ne réside pas dans la biométrie, mais dans la mécanique du vol. Humanity est le troisième grand hack de 2026 qui ne brise pas une seule ligne de code d'un contrat intelligent et s'attaque, à la place, à la personne qui détient les clés. Cela s'inscrit dans un schéma que nous avons déjà documenté : les attaques visent l'infrastructure et le périmètre humain, pas le contrat. Ici, le périmètre était un ordinateur portable.

Comment le vol a-t-il été exécuté sur trois vecteurs simultanés ?

L'attaquant ne s'est pas contenté de vider un portefeuille chaud. Une fois le contrôle de l'appareil du directeur obtenu, il a attaqué trois surfaces simultanément le même jour, exploitant chaque permission accordée par ces clés.

Le bridge (pont qui déplace des tokens entre deux blockchains en les verrouillant sur l'une et en les représentant sur l'autre) a été le coup le plus net : avec trois des six signatures nécessaires, l'attaquant a mis à jour le contrat du pont vers une version qu'il contrôlait et a extrait plus de 141 millions de tokens H. Sur BSC, il a exploité le ProxyAdmin — le contrat administrateur qui décide quel code un contrat évolutif exécute — pour activer la capacité de frapper de nouveaux tokens à partir de rien. C'est là qu'il faut lire le chiffre avec prudence : 300 millions de H ont été autorisés pour le mint, dont environ 200 millions ont été exécutés dans la phase initiale. L'offre soudaine, déversée sur Uniswap et d'autres DEX (exchanges décentralisés), a effondré le prix.

Les trois vecteurs partagent une même origine et c'est pourquoi ils ont pu être déclenchés en même temps : les clés qui autorisaient chacun d'eux — signer sur le bridge, administrer le proxy, déplacer le hot wallet — étaient à la portée du même appareil compromis. Un attaquant avec un seul point de contrôle n'a pas eu à choisir ; il a exécuté les trois routes en parallèle le même jour. Cette simultanéité est la signature d'une compromission d'appareil, et non d'un exploit ponctuel : quand l'origine des signatures tombe, toutes les surfaces gouvernées par ces signatures tombent également.

Pourquoi un multisig 3-sur-6 n'a-t-il pas suffi ?

C'est la question cruciale, et la réponse est contre-intuitive. Un multisig 3-sur-6 semble robuste : aucun signataire ne peut déplacer des fonds seul, et l'on tolère la défaillance de plusieurs clés. Sur le papier, six personnes ou appareils se partagent le pouvoir.

Ce schéma ne tient sa promesse que si ces six clés sont réellement séparées : différentes personnes, différents appareils, idéalement différents lieux physiques et, pour les plus sensibles, du hardware air-gapped (isolé du réseau). La sécurité d'un seuil cryptographique dépend du fait que la compromission d'une clé ne rapproche pas l'attaquant des autres. Si trois clés — ou plus, en comptant les sauvegardes — cohabitent sur le même ordinateur portable, l'attaquant qui prend le contrôle de cet ordinateur n'a pas besoin de briser le schéma : il le satisfait. Il réunit le seuil en un seul mouvement. Chez Humanity, selon le rapport forensique de l'équipe, jusqu'à sept clés de signataire — en cumulant celles des deux multisig et leurs sauvegardes — étaient à la portée d'un unique appareil : sur le papier un 3-sur-6 et un 3-sur-5 ; en pratique, un 1-sur-1, car il suffisait de compromettre cette machine pour toutes les obtenir.

En d'autres termes : la distribution physique n'est pas la même chose que le seuil cryptographique. La redondance numérique du 3-sur-6 était fictive car la redondance physique n'existait pas. Le multisig était bien configuré dans le contrat, mais mal déployé dans le monde réel. C'est exactement la faille qui sépare la théorie de la gestion de clés de sa pratique, et la raison pour laquelle un lecteur débutant devrait d'abord comprendre ce qu'est et ce que ne garantit pas un multisig avant de lui confier des fonds.

Comment l'attaquant est-il entré et quelle trace pointe vers la Corée du Nord ?

Le point d'entrée n'était pas cryptographique, mais social. Le 5 juin, trois jours avant le drainage, un e-mail de spear-phishing imitant Bithumb, l'un des grands exchanges coréens, est arrivé. Chong Yee Wai, directeur de la Humanity Foundation, a mordu à l'hameçon et l'appareil a été infecté par un malware signé avec un certificat de Hancom — un fournisseur de logiciels sud-coréen —, une technique de signature volée qui donne une apparence de légitimité à l'exécutable.

Cet ensemble d'indicateurs — spear-phishing usurpant un exchange, malware avec certificat coréen compromis, cible dans l'écosystème asiatique — correspond au modus operandi d'acteurs parrainés par la Corée du Nord (DPRK). La société de sécurité Quantstamp, après avoir analysé l'incident, a trouvé des schémas caractéristiques des intrusions DPRK, mais n'a pas émis d'attribution définitive ni nommé de sous-groupe concret. C'est une nuance importante : il y a une empreinte, mais pas de confirmation nominale. Le schéma DPRK est déjà largement documenté dans d'autres hacks de 2026, et nous le couvrons en détail dans l' analyse de la trace de 577 millions à travers Drift et Kelp ; ici, il suffit de situer Humanity dans cette série sans reproduire le dossier.

Était-ce un rug pull (fraude interne) ou un hack externe ?

Durant les premières heures suivant le vol de Humanity, la suspicion d'un incident orchestré de l'intérieur a circulé. Le chercheur on-chain ZachXBT l'a qualifié le 9 juin de "possibly staged" — possiblement mis en scène —, une hypothèse raisonnable quand l'argent sort des portefeuilles de l'équipe elle-même. Peu après, il a révisé cette lecture.

Sa conclusion finale a été plus nuancée qu'un simple "c'était un hack" ou "c'était un rug pull" : l'activité du market maker (le teneur de marché qui apporte de la liquidité au token) et la compromission de la clé sont des événements indépendants. Autrement dit, ce qui ressemblait à une coordination interne était le bruit de deux choses se produisant en même temps sans être liées. ZachXBT n'a pas affirmé avoir confirmé une exfiltration externe avec une preuve irréfutable ; il a écarté le récit du montage interne comme explication nécessaire. L'arc complet — suspicion, révision, séparation des deux faits — fait partie de la valeur de ce cas : il montre à quel point il est difficile de distinguer un vol d'une fraude lorsque les fonds sortent de portefeuilles propres.

Que dit la chronologie de l'attaque ?

La séquence datée montre clairement que le vol n'a pas été un instantané, mais une opération avec des jours de préparation et une suite qui reste ouverte.

Quelles leçons de gestion de clés ce cas laisse-t-il ?

Au-delà des noms et des chiffres, Humanity est un manuel de ce qu'il ne faut pas faire lors de la garde de clés institutionnelles. Les trois leçons opérationnelles :

• Séparation physique réelle, pas nominale. Les signatures d'un multisig doivent résider sur des appareils différents, entre les mains de personnes différentes. Co-localiser plusieurs clés — ou leurs sauvegardes — sur une seule machine transforme un 3-sur-6 en un 1-sur-1 déguisé. Le chiffre du seuil ne signifie rien si la distribution physique ne le soutient pas.
• Air-gap pour les clés qui déplacent la trésorerie. Les signatures ayant un pouvoir sur les bridges, le mint et le ProxyAdmin ne devraient jamais toucher un ordinateur portable connecté à une messagerie électronique. L'appareil qui ouvre un PDF de Bithumb ne peut pas être le même que celui qui garde la clé du pont.
• Séparation des environnements et timelock sur les contrats critiques. Le ProxyAdmin qui permet de mettre à jour un contrat ou de frapper des tokens devrait être derrière un timelock (délai obligatoire entre l'ordre et l'exécution) pour donner le temps de détecter et d'annuler un ordre malveillant. Sans cette pause, réunir le seuil équivaut à une exécution instantanée, comme ce fut le cas ici.

Ce dernier point fait écho à un précédent direct de 2026 : le hack de Drift Protocol en avril, où un multisig également compromis a permis à des acteurs avec une empreinte DPRK d'exécuter des actions sans frein. Le schéma se répète : on ne brise pas la cryptographie, on brise le processus humain qui l'entoure. Pour le lecteur individuel, la version domestique de cette même erreur est exactement celle que nous décrivons dans comment les gens perdent leurs cryptomonnaies : la dérive opérationnelle, et non la faille du protocole.

La différence entre les protocoles qui survivent à une compromission de clés et ceux qui n'y survivent pas se résume souvent à savoir si le contrat administrateur avait un timelock. Avec un délai obligatoire entre l'ordre de mise à jour et son exécution, l'équipe de Humanity aurait eu une fenêtre — des heures, pas des secondes — pour détecter la mise à jour malveillante du bridge et la révoquer avant que quoi que ce soit ne soit drainé. Sans timelock, réunir trois signatures et vider le pont sont un seul et même acte. Le ProxyAdmin de BSC qui reste compromis à ce jour est l'autre face du même problème : un administrateur sans frein temporel est un passe-partout permanent, et tant que l'attaquant le conserve, le risque de nouvelle frappe ne disparaît pas. Le coût de l'ajout de ce timelock est de quelques minutes de friction opérationnelle ; le coût de son absence, dans ce cas, a été de dizaines de millions.

Quel est l'état du projet et de la récupération ?

Au 17 juin, la situation restait ouverte sur un point critique : le ProxyAdmin de BSC continuait d'être sous le contrôle de l'attaquant, ce qui maintient la capacité de frapper davantage de tokens. Sur les 300 millions de H autorisés pour le mint, environ 200 millions avaient été exécutés ; la marge restante est le risque qui continue de peser sur le réseau BSC.

Du côté de la réponse, le 16 juin, l'équipe a annoncé son plan de récupération : un airdrop 1:1 (distribution gratuite de tokens aux personnes affectées) d'un nouveau token H, cette fois sous forme d'ERC-20 sur Ethereum, en prenant comme référence un snapshot (instantané de l'état du réseau) antérieur à l'attaque. Il ne s'agit pas d'un "H2" ni d'un ratio étrange — c'est un remplacement un pour un du token affecté. L'efficacité de ce plan dépend de la fermeture préalable du ProxyAdmin compromis ; sinon, le nouveau token hérite du même risque d'offre incontrôlée. Au 17 juin, l'équipe elle-même qualifiait le H de BSC de "définitivement compromis" et n'avait pas repris le contrôle du ProxyAdmin.

Qu'est-ce qui change dans la gestion des clés après le cas Humanity ?

Humanity Protocol n'a pas été hacké à cause d'un mauvais contrat ou d'un mauvais multisig. Il a été hacké pour avoir déployé un bon multisig de telle sorte que sa garantie n'existait pas. La leçon n'est pas "utilisez un multisig" — il en utilisait déjà un —, mais que le schéma ne vaut que ce que vaut la séparation physique et opérationnelle de ses clés. Trois signatures sur six ne protègent rien si trois signatures résident sur le même disque dur.

Pour 2026, c'est désormais le schéma dominant des grands vols : l'ingénierie sociale contre une personne ayant un accès, et non des exploits contre le code. Trois des plus grands incidents de l'année — Drift et Kelp en avril, Humanity en juin — partagent le même squelette : empreinte d'acteurs DPRK, entrée par compromission humaine ou sociale, et un mécanisme de contrôle (multisig ou administrateur de proxy) qui est satisfait au lieu d'être brisé. Le périmètre défendable s'est déplacé du contrat vers l'ordinateur portable. Quiconque garde des fonds — institution ou individu — défend aujourd'hui un appareil et un processus, pas seulement une ligne de Solidity.

La question pratique pour toute équipe lisant ceci n'est pas "avons-nous un multisig ?", mais trois questions plus inconfortables : où résident physiquement nos clés, y compris les sauvegardes ? Combien d'entre elles pourraient être réunies par quelqu'un compromettant un seul appareil ? Et combien de temps un timelock nous donnerait-il pour annuler un ordre malveillant ? Humanity a échoué aux trois. Y répondre correctement n'est pas glamour et ne figure pas sur la roadmap, mais c'est la différence entre une frayeur et un titre de presse à 36 millions.

Sources et liens : Rekt.news — Humanity Protocol post-mortem (16-juin-2026) · Halborn — analyse technique du hack · crypto.news — analyse de ZachXBT · CryptoBriefing — schémas DPRK (Quantstamp) · CryptoTimes — plan de récupération et airdrop · CoinDesk — le multisig qui vivait sur un seul ordinateur portable