Hack Alephium : 815 000 $ volés en 7 minutes via 3 clés compromises

Comment l’attaque a-t-elle été réalisée ?

L’exploit repose sur un mécanisme simple mais dévastateur. Le bridge d’Alephium utilise un système de 4 clés de guardian pour valider les transferts cross-chain. Dès lors qu’une majorité de 3 sur 4 signe une attestation, celle-ci est considérée comme légitime.

Les attaquants ont compromis 3 de ces 4 clés, suffisamment pour forger de fausses attestations VAA (Verified Action Approval). Ces messages frauduleux ont convaincu le contrat de libérer les actifs du pool de dépôt. En 7 minutes, USDT, USDC, WBTC et WETH ont été extraits, tandis que 13,76 millions de wrapped ALPH étaient émis sans la moindre contrepartie réelle. Cette mécanique rappelle l’attaque sur le Nomad Bridge, où des messages mal validés avaient également permis des retraits non autorisés.

Ce n’est pas une faille dans le code des smart contracts. C’est une défaillance opérationnelle : la gestion des clés privées guardian est le maillon faible.

Pourquoi l’émission d’ALPH non garantis est-elle problématique ?

Au-delà des 815 000 $ disparus, le vrai risque systémique est ailleurs. Les 13,76 millions de wrapped ALPH émis sans actifs sous-jacents représentent un token fantôme circulant dans l’écosystème. Si ces jetons venaient à être vendus massivement, ils exerceraient une pression vendeuse artificielle sur le prix de l’ALPH, sans qu’aucun ALPH réel n’ait été bloqué en contrepartie.

Ce scénario est distinct d’un simple vol de liquidités. Il crée une distorsion entre l’offre réelle et l’offre affichée du token bridgé. On retrouve un mécanisme analogue dans le hack BitMart, où des jetons avaient été retirés puis potentiellement revendus pour liquider l’exposition. Ici, le volume émis (13,76 millions) dépasse probablement la liquidité disponible sur les marchés secondaires.

À l’heure de la publication, les fonds volés n’ont pas bougé du wallet de l’attaquant selon les informations disponibles. Aucune tentative de blanchiment via un mixer n’a été signalée pour l’instant.

Quelle différence avec une faille de smart contract ?

La distinction est importante pour évaluer la gravité et la remédiation. Une faille de contrat est un bug de code : elle peut être patchée via un upgrade. Une compromission de clés, en revanche, est une faille humaine ou organisationnelle. Elle implique que les clés privées ont été volées, phishées ou exposées d’une manière ou d’une autre.

Ce type d’incident est difficile à prévenir par le seul audit de code. Les solutions passent par la répartition géographique des signataires, l’usage de hardware security modules (HSM) et des procédures de rotation régulière des clés. Des protocoles comme Verus Bridge ou DxSale ont subi des vecteurs différents, mais le résultat est similaire : la confiance dans un pont cross-chain peut être brisée en quelques minutes dès que la couche de gouvernance est compromise.

Le schéma 3/4 de multisignature, souvent présenté comme sécurisé, ne l’est que si les clés sont réellement indépendantes et bien protégées. Si trois signataires partagent la même infrastructure ou sont ciblés simultanément, la sécurité nominale s’effondre.

Les incidents récents sur les bridges cross-chain confirment un constat récurrent : la sécurité d’un pont n’est pas seulement une question d’audit de smart contracts. La couche de gouvernance des clés est aussi critique que le code lui-même.

La récurrence de ces attaques a d’ailleurs conduit LayerZero à admettre une faille DVN liée au hack Kelp de 292 M$, un épisode qui avait mis en lumière des limites structurelles similaires dans les systèmes de validation cross-chain.

À retenir

Le hack Alephium illustre, une fois de plus, la vulnérabilité des bridges multi-signatures face à la compromission de clés. Avec 815 000 $ dérobés et 13,76 millions d’ALPH non garantis en circulation, l’équipe devra traiter à la fois la remédiation technique et le risque de pression sur le token. Les prochaines heures seront déterminantes pour savoir si l’attaquant tente de liquider sa position.