Contexte de l’incident

Le 6 septembre 2026 à 13:53 UTC (bloc Liquid 4 050 336), un attaquant a exploité une vulnérabilité du cache de vérification des rangeproofs d’Elements. Cette faille a permis à une transaction d’être acceptée alors que la valeur de sortie n’était pas couverte par les entrées, créant ainsi environ 4 000 LBTC sans BTC sous‑jacent. Les nœuds du réseau, y compris les 15 nœuds fonctionnaires de la fédération, ont validé la transaction.

Le montant non garanti a été transféré via le processus de peg‑out standard, en utilisant SideSwap, membre de la fédération détenteur d’une Peg‑out Authorization Key (PAK). Le retrait a abouti à une sortie d’environ 4 000 BTC confirmée dans le bloc Bitcoin 965 783. Des peg‑outs plus petits ont réduit la réserve Liquid de ~4 205 BTC à 197 BTC avant l’arrêt du réseau.

L’auteur a identifié son adresse sur‑chaîne quelques heures plus tard et a restitué 3 400 BTC le 7 septembre 2026 à 16:09 UTC (bloc Bitcoin 965 950). Il reste environ 602 BTC non récupérés.

Analyse de la vulnérabilité

Deux facteurs ont concouru à l’incident : (1) des failles de consensus dans Elements, désignées Bug A et Bug B, et (2) une mauvaise configuration du processus de signature PAK d’un membre. Le Bug A provient d’un commit d’avril 2018 (PR #335) intégré dans Elements v0.14.1 le 30 mai 2018. Ce commit a simplifié la clé du cache de rangeproof en excluant l’identifiant de l’actif, ce qui a rendu possible la réutilisation d’une preuve valide pour un actif différent. Le Bug B, non détaillé dans le rapport, concernait la validation des preuves de surjection.

Le mécanisme de peg‑out repose sur deux clés : une clé hors‑ligne (xpub) stockée dans un portefeuille froid, et une clé en ligne (secp256k1) résidente sur le nœud. La clé hors‑ligne assure que les BTC restent sous contrôle même si la validation de consensus accepte des LBTC erronés. Dans ce cas, la configuration du membre a permis à la clé en ligne de signer un peg‑out sans la vérification supplémentaire attendue, ouvrant une voie directe vers le portefeuille Bitcoin.

Chronologie et réponses

Après la première transaction, Blockstream a suspendu les nœuds de pont Liquid, déployé un correctif d’urgence en quelques heures, puis publié une version durcie Elements v23.3.4 quelques jours plus tard. La pause du réseau a limité l’exposition des autres actifs (USDt, DePix, etc.), qui sont restés intacts mais inaccessibles pendant la période d’arrêt.

Le processus de récupération a impliqué des négociations avec l’attaquant, aboutissant au retour partiel des fonds. Les 602 BTC restants sont toujours en suspens, et la fédération surveille les adresses associées pour détecter d’éventuels mouvements.

Implications et leçons

Cette attaque montre que la confiance d’une side‑chain repose entièrement sur la robustesse du code de consensus. Un cache mal conçu peut compromettre l’intégrité des rangeproofs, qui sont au cœur de la confidentialité et de la garantie d‑émission des actifs. La double‑clé du PAK offre une protection résiliente, mais elle dépend d’une configuration stricte ; toute déviation crée un point d’entrée exploitable.

Les correctifs apportés (optimisation du cache, renforcement des vérifications de surjection) réduisent le risque de réutilisation de preuves entre actifs. Le rapport recommande une revue continue du code de consensus, des tests de fuzzing ciblés sur les caches, et une surveillance accrue des signatures PAK afin d’éviter des dérives similaires.