Une faille du logiciel Elements a permis le retrait d’environ 4 000 BTC du portefeuille de la fédération Liquid. Leur valeur atteignait près de 320 millions de dollars lors de l’incident.

Ce montant représentait environ 95 % des 4 200 BTC conservés dans ce portefeuille. Liquid a donc suspendu les nouvelles transactions pendant le traitement de l’incident.

Une faille sur Liquid, pas sur Bitcoin

La faille n’a pas touché le protocole Bitcoin. Elle concernait Liquid, une chaîne secondaire qui utilise son propre modèle de sécurité.

Lorsqu’un utilisateur dépose des bitcoins sur Liquid, la fédération conserve les BTC sur la chaîne principale. Le réseau émet alors la même quantité de L-BTC.

Un retrait, appelé peg-out, suit le chemin inverse. Les L-BTC sont détruits, puis la fédération libère les BTC correspondants.

⚠️ Piratages DeFi 2026 : les failles de bridge explosent

Le cache oubliait deux éléments

Liquid utilise des transactions confidentielles pour masquer les montants et les actifs transférés. Des preuves d’intervalle garantissent cependant la validité des valeurs cachées.

Ces contrôles demandent beaucoup de calculs. Elements utilisait donc un cache afin d’éviter plusieurs vérifications identiques.

Le cache associait chaque validation aux éléments suivants :

• les données de la preuve d’intervalle ;
• l’engagement cryptographique représentant la valeur.

Cependant, il ne prenait pas en compte deux informations indispensables :

• l’engagement correspondant au type d’actif ;
• le script définissant les conditions d’utilisation de la sortie.

Un attaquant pouvait ainsi réutiliser une preuve déjà acceptée dans un autre contexte. Le cache répondait alors favorablement sans relancer la vérification complète.

Comment de faux L-BTC ont pu apparaître

L’analyse technique disponible décrit un mécanisme en plusieurs étapes. Certains détails nécessitent encore une confirmation officielle.

1. L’attaquant fait d’abord vérifier une preuve valide par certains nœuds.
2. Ces nœuds enregistrent le résultat dans leur cache.
3. L’attaquant réutilise ensuite cette preuve avec un actif ou un script différent.
4. Le cache accepte une sortie qui aurait échoué lors d’un contrôle complet.
5. Cette sortie pourrait cacher une valeur négative.
6. La valeur négative compense artificiellement une sortie positive contenant des L-BTC.
7. Les L-BTC ainsi créés servent ensuite à demander de vrais BTC.

L’attaquant n’aurait donc pas volé les clés du portefeuille fédéral. Le système aurait libéré de vrais bitcoins après avoir validé des L-BTC créés artificiellement.

Des nœuds Liquid en désaccord

Le cache restait dans la mémoire de chaque nœud. Un redémarrage pouvait donc supprimer les preuves précédemment enregistrées.

Les nœuds dont le cache avait été préparé pouvaient accepter la transaction. En revanche, les autres nœuds la rejetaient.

Ce fonctionnement expliquerait la divergence observée entre la fédération et certains explorateurs. Deux serveurs utilisant la même version pouvaient afficher des résultats différents.

Près de 3 998,67 BTC retirés

L’analyse indépendante situe le début de la rupture de consensus le 6 septembre 2026, vers 14 h 40, heure de Paris.

Environ neuf minutes plus tard, deux demandes de retrait totalisaient 3 998,67 BTC. La fédération les aurait ensuite traitées vers 16 h 25.

La principale transaction Bitcoin a déplacé près de 3 996 BTC. Leur valeur atteignait environ 318,4 millions de dollars lors de sa confirmation.

SideSwap et la clé d’autorisation

Les retraits ont utilisé la clé d’autorisation de SideSwap. Il s’agit bien de SideSwap, et non du service distinct SideShift.

Une telle clé prouve que l’adresse destinataire appartient à un membre autorisé. Elle ne valide pas automatiquement l’origine économique des L-BTC présentés.

Liquid affirme que la clé de SideSwap n’a pas été compromise. La faille se situerait donc dans Elements et sa validation des transactions confidentielles.

Un correctif visible avant l’attaque

Le correctif ajoute l’actif et le script de sortie aux informations enregistrées dans le cache. Il confirme donc directement la nature de l’erreur.

Le commit porte une date d’auteur du 3 août 2026. Les développeurs l’ont intégré à la branche principale le 1er septembre.

Ils l’ont ensuite ajouté aux branches 23.x les 2 et 3 septembre. Cependant, aucune version officielle publiée ne semblait encore contenir la correction.

L’attaque est survenue le 6 septembre. La publication du correctif a donc pu révéler la faille avant son déploiement général. Cette chronologie reste une hypothèse sérieuse, mais non confirmée.

Les auteurs évoquent une restitution partielle

Les auteurs ont inscrit le message « we are whitehats. contact us on chain » dans une transaction Bitcoin. Ils affirment donc agir comme des chercheurs en sécurité.

Des messages ultérieurs proposent de restituer la majorité des bitcoins. Les auteurs demandent toutefois le déploiement préalable du correctif sur tous les nœuds.

Cette déclaration ne garantit rien. L’identité des auteurs reste inconnue et la promesse ne concerne pas forcément la totalité des fonds.

Trois questions restent ouvertes

Pourquoi le correctif n’a-t-il pas été déployé ?

Le code corrigé existait avant l’exploitation. Cependant, les opérateurs ne disposaient pas encore d’une version officielle intégrant cette modification.

Un rapport devra préciser qui connaissait la gravité du problème. Il devra aussi expliquer pourquoi les opérateurs sensibles n’ont pas reçu la correction plus tôt.

Pourquoi un retrait aussi important a-t-il été accepté ?

Le système a traité un retrait proche de 4 000 BTC. Des plafonds, une limite quotidienne ou une validation humaine auraient peut-être réduit les pertes.

La fédération devra donc détailler les contrôles appliqués aux retraits exceptionnels. Elle devra également expliquer le rôle exact de la clé SideSwap.

Pourquoi les explorateurs ont-ils divergé ?

Le cache local fournit l’explication la plus probable. Certains nœuds avaient enregistré la preuve nécessaire, tandis que d’autres ne la possédaient pas.

Les journaux techniques devront néanmoins confirmer cette hypothèse. Ils permettront aussi d’identifier les nœuds ayant suivi chaque branche.

🔍 DUC, mon avis

Cette affaire rappelle une différence essentielle : Liquid utilise Bitcoin, mais n’offre pas sa sécurité. Une petite optimisation a suffi pour menacer presque toute sa réserve. La promesse de restitution reste positive. Cependant, 4 000 BTC constituent une méthode d’audit légèrement musclée.

Subissons-nous les mêmes failles que dans les altcoins ?

Oui, dès que nous quittons la chaîne principale de Bitcoin. Les sidechains, ponts et services fédérés réintroduisent des risques comparables : bugs, intermédiaires et règles de gouvernance.

• Cette faille touche donc Liquid, pas Bitcoin. Elle rappelle que posséder un actif lié au BTC ne garantit pas automatiquement la sécurité du réseau Bitcoin.

En Bref

Le correctif identifie clairement le défaut du cache. Cependant, la restitution des fonds et la chronologie interne restent incertaines. La confiance dépendra désormais du rapport officiel, des nouveaux contrôles et du retour effectif des bitcoins.

✍️ DUC
Sources : Liquid Network — déclaration officielle · Elements — correctif du cache · Blockstream — fonctionnement des retraits · Mempool.space — message inscrit · Mempool.space — échange suivant · Analyse technique indépendante

🚀 Rejoignez-moi pour plus de contenu exclusif !

• 👉 YouTube : Bitcoin sans détour
• 👉 X : @bitcoinduc

📢Prendre des décisions informées dans cet univers passionnant ! Comprendre, Apprendre, Réussir…

• Sur YouTube : toute l’actualité de Bitcoin et un regard averti sur l’ensemble de l’univers des cryptomonnaies.

🔔 Abonnez-vous au site pour ne manquer aucun contenu

À bientôt, DUC