Post-mortem : anatomie du hack Liquid à 265 millions d’euros

Le 6 septembre 2026 à 15 h 53 UTC, un attaquant a fait naître près de 4 000 L-BTC qui n’existaient pas une seconde plus tôt, puis les a convertis en bitcoins natifs. En quelques heures, l’équivalent d’environ 265 millions d’euros (quelque 320 millions de dollars au moment des faits) a quitté la réserve fédérée du Liquid Network, la sidechain Bitcoin opérée par Blockstream et utilisée par des dizaines de plateformes d’échange, comme l’a documenté CoinDesk. Au cours du week-end, la sidechain a cessé de produire des blocs, une correction d’urgence a été déployée, et une partie des fonds est revenue. À première vue, un braquage on-chain de plus dans une année 2026 déjà lourde.

Sauf que cette affaire sort du lot pour deux raisons. La première : il ne s’agit pas de clés volées, mais d’un vrai bug de code, une espèce devenue rare dans une année où l’essentiel des pertes provient de la compromission d’humains et de signatures. La seconde : ce que l’industrie retiendra n’est pas tant le hold-up que le document censé le suivre, le post-mortem, et la bataille publique qui s’est nouée autour de lui.

Un post-mortem d’exploit n’est pas un communiqué de presse. C’est un rapport d’incident qui répond à trois questions : qu’est-ce qui a cassé, qu’est-ce qui a été perdu, et qu’est-ce qui va changer. Bien fait, il fait progresser tout l’écosystème. Bâclé, trop lisse ou publié trop tard, il devient un exercice de relations publiques. L’affaire Liquid, avec son différend ouvert sur la divulgation, sa querelle sémantique autour du « white hat » et son refus assumé de payer une rançon, offre un cas d’école pour comprendre ce qui sépare un vrai post-mortem d’un habillage.

« Post-mortem » : ce que le mot veut vraiment dire

Emprunté à la médecine légale, le terme « post-mortem » désigne l’autopsie d’un incident. Dans la culture de l’ingénierie, il vient des équipes de fiabilité (les SRE) qui, après chaque panne, rédigent un compte rendu détaillé pour éviter la récidive. La crypto a hérité de cette pratique, avec une contrainte supplémentaire : ici, la panne se chiffre souvent en dizaines de millions, et le rapport est lu par des attaquants autant que par des développeurs.

Un post-mortem digne de ce nom contient plusieurs briques : un résumé de l’incident, une chronologie horodatée (en UTC, pour lever toute ambiguïté), une cause racine nommée sans détour, les facteurs aggravants, un chiffrage de l’impact, les mesures d’urgence prises, puis un plan de remédiation avec des actions datées et un responsable pour chacune. Le média spécialisé rekt.news, qui dissèque les exploits depuis des années, rappelle une règle simple : un rapport qui n’aboutit à aucune action concrète n’est pas un post-mortem, c’est une consolation.

La deuxième exigence est culturelle : le post-mortem doit être « blameless », c’est-à-dire sans recherche de bouc émissaire. L’idée, importée des grandes équipes d’infrastructure, est que punir l’erreur humaine pousse les gens à la cacher, alors que documenter chaque erreur pour la transformer en garde-fou technique améliore le système. Pour chaque faute humaine identifiée, un vrai post-mortem propose une barrière automatique correspondante. C’est précisément sur ce point, on le verra, que l’affaire Liquid s’est tendue.

Chronologie : du 1er au 11 septembre

La force d’un post-mortem tient d’abord à sa chronologie. Voici celle de l’incident Liquid, reconstituée à partir du rapport d’incident publié par le réseau et des analyses techniques indépendantes.

Ce tableau, en apparence anodin, contient déjà le nœud de l’affaire : la ligne du 1er septembre. Cinq jours avant le vol, le correctif existait, publiquement, dans le code source. Nous y reviendrons, car c’est cette ligne qui a mis le feu aux poudres.

La faille : une collision de clé de cache

Pour valider une transaction confidentielle, Liquid s’appuie sur des « rangeproofs », des preuves cryptographiques (des bulletproofs) qui garantissent qu’un montant caché est bien positif, sans en révéler la valeur. Vérifier ces preuves coûte cher en calcul. Comme la plupart des logiciels de nœud, Elements met donc en cache les résultats de vérification : une preuve déjà validée n’est pas recalculée si elle se représente. Cette optimisation est banale et, en principe, sans danger.

Le problème tenait à la façon dont le logiciel construisait la clé d’entrée de ce cache. Selon l’analyse de SlowMist, cette clé était un hash salé calculé sur la simple concaténation de plusieurs champs : la preuve, l’engagement (commitment), le générateur d’actif et le scriptPubKey, sans aucun délimiteur de longueur. Or deux de ces champs sont de taille variable et se trouvent aux extrémités opposées du flux. En déplaçant la frontière entre eux, un attaquant pouvait faire en sorte que deux ensembles de données pourtant différents produisent exactement la même suite d’octets, donc la même clé de cache.

La conséquence est vertigineuse : une preuve valide, déjà mise en cache, pouvait « couvrir » une preuve invalide entrant en collision avec elle. Le nœud consultait son cache, y trouvait un verdict « valide » et laissait passer une transaction qui aurait dû être rejetée. C’est ce que CertiK décrit comme une collision de clé de cache : la faille n’était pas dans la cryptographie des bulletproofs elle-même, réputée solide, mais dans la plomberie d’optimisation autour d’elle. Résultat, l’attaquant a pu forger des preuves acceptées à tort et créer près de 3 998 L-BTC à partir de rien, avant de les échanger contre du bitcoin réel via une plateforme approuvée du réseau, incapable de distinguer les jetons frauduleux des authentiques.

Le correctif, sobrement intitulé « sigcache: harden range proof cache keys », durcit le calcul de cette clé et ajoute une option permettant de désactiver entièrement le cache de rangeproofs. Il a été publié dans Elements v23.3.4 le 9 septembre, comme l’indiquent les notes de version sur GitHub. Un correctif d’une simplicité déconcertante pour une faille à neuf chiffres.

Un bug de code dans un monde de clés volées

Ce qui rend l’incident Liquid presque anachronique, c’est sa nature. En 2026, le code n’est plus le maillon faible. Selon les données compilées par CertiK et reprises par crypto.news, la DeFi a perdu au moins 1,3 milliard de dollars sur les huit premiers mois de l’année, et la majorité de cette somme provient de clés privées ou d’accès administrateurs compromis, pas de bugs de contrat intelligent.

Le cofondateur de CertiK, Ronghui Gu, résume la bascule sans détour : « A protocol can pass a flawless code audit and still lose millions because of a compromised admin key » (un protocole peut réussir un audit de code sans faute et perdre malgré tout des millions à cause d’une clé d’administration compromise). Autrement dit, la surface d’attaque a migré vers le haut de la pile : les signataires, la gouvernance, les humains.

Les quatre premières lignes de ce tableau proviennent du décompte de crypto.news ; la cinquième, c’est Liquid. Dans ce paysage, la sidechain fait figure d’exception : un vrai bug de code, dans un logiciel open source audité, revu et éprouvé depuis des années. C’est aussi ce qui rend son post-mortem si intéressant, parce qu’il ne peut pas se cacher derrière « on nous a volé nos clés ». Le fautif est ici une ligne de code, et il porte un nom, un numéro de commit et une date.

La fédération 11 sur 15 : la multisig n’a rien vu venir

Liquid n’est pas une blockchain ouverte comme Bitcoin. C’est une sidechain fédérée : un consortium de membres (plateformes d’échange, teneurs de marché, sociétés d’infrastructure) opère le réseau. La garde des bitcoins mis en réserve repose sur un ensemble de nœuds signataires, les « functionaries », et sur une multisig où onze signatures sur quinze sont nécessaires pour autoriser un peg-out, c’est-à-dire un retrait vers la chaîne Bitcoin principale.

On pourrait croire qu’une telle multisig protège d’un vol. Elle protège d’un type de vol : celui où un attaquant s’empare d’une clé, ou même de plusieurs. Elle ne protège pas d’un bug de consensus. Dans l’incident du 6 septembre, les onze functionaries ont signé un peg-out qui leur paraissait parfaitement légitime, parce que leurs propres nœuds, exécutant le code vulnérable, considéraient les L-BTC frauduleux comme authentiques. La multisig a fonctionné exactement comme prévu ; c’est la réalité qu’elle validait qui était faussée.

C’est une leçon récurrente des post-mortems de dépositaires : la sécurité d’une réserve ne vaut que celle du logiciel qui décide ce qui est vrai. Multiplier les signataires ne sert à rien si tous consultent la même vérité corrompue. Le sujet rejoint un débat plus large sur la garde institutionnelle, à l’heure où les plus gros mouvements on-chain sont le fait de dépositaires et non plus de baleines individuelles. Quand la valeur se concentre derrière quelques clés partagées, le point de défaillance se déplace du portefeuille vers le code qui l’orchestre.

Le patch qui n’était pas silencieux

Revenons à la ligne du 1er septembre. La correction du bug de cache n’a pas été découverte par l’attaquant au prix d’un travail de reverse engineering : elle était déjà publique, fusionnée dans le dépôt Elements sur GitHub, cinq jours avant l’exploitation. Pire, elle portait un intitulé descriptif qui pointait précisément la nature du problème.

C’est le scénario du cauchemar en sécurité open source : le « N-day ». Un correctif publié avant d’être déployé partout est une carte routière offerte aux attaquants. Ceux qui surveillent les commits des logiciels critiques, et ils sont nombreux, lisent chaque changement de code comme un indice. Un correctif de sécurité annoncé comme tel, sans coordination de déploiement, revient à publier la combinaison du coffre en promettant de changer la serrure « bientôt ».

La bonne pratique, dans ce cas, est la divulgation coordonnée : on prépare le correctif en privé, on donne aux opérateurs de nœuds le temps de se mettre à jour, puis on publie les détails. Le fait que le correctif Liquid ait été visible, décrit et non déployé pendant cinq jours est, du strict point de vue du post-mortem, la question la plus importante de toute l’affaire. Comment un patch de sécurité critique a-t-il pu rester exposé si longtemps sans mise à jour coordonnée des functionaries ? C’est là que le récit officiel et celui de ses détracteurs divergent.

White hat ou voleur ? La bataille sémantique

L’attaquant s’est présenté comme un « white hat », un hacker éthique. Il a communiqué avec Blockstream par messages inscrits directement sur la chaîne Bitcoin, avec une offre conditionnelle : « Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix » (corrigez d’abord le bug ; la chaîne est en danger ; assurez-vous que chaque nœud est patché ; ensuite nous renverrons l’argent en toute sécurité), rapporte CoinDesk.

Il a tenu parole à 85 %. Le 7 septembre, environ 3 400 BTC sont revenus dans le portefeuille de la fédération. Restaient environ 598,5 BTC, soit près de 40 millions d’euros (environ 47 millions de dollars), que l’attaquant proposait de conserver au titre d’une « prime » de 10 %.

Blockstream a refusé net. Dans une déclaration reprise par The Block, l’entreprise tranche : « Taking assets without authorization and withholding their return is a crime, not responsible disclosure. It is not white-hat activity. It is theft » (prendre des actifs sans autorisation et retenir leur restitution est un crime, pas une divulgation responsable ; ce n’est pas du white-hat, c’est du vol). L’argument de fond : céder reviendrait à instaurer un précédent où des développeurs open source doivent payer des rançons supérieures à leur propre participation économique au projet.

La frontière entre white hat et maître chanteur est effectivement ténue. La règle communément admise dans la sécurité offensive est simple : un white hat ne prend pas les fonds. Il démontre la faille, alerte, et laisse l’argent en place. Prélever d’abord, négocier ensuite, puis conserver une part « en récompense » relève d’une autre catégorie, quel que soit le vocabulaire employé. Ce débat n’est pas neuf ; il ressurgit à chaque gros exploit dit « amiable », et il empoisonne systématiquement la rédaction sereine d’un post-mortem.

Le différend sur la divulgation

C’est ici que le post-mortem cesse d’être un document et devient un champ de bataille. Un collectif de sécurité bénévole, la Bitcoin Red Team, affirme avoir prévenu Blockstream avant le hack. Son colead, connu sous le pseudonyme Calle, a résumé sa position d’une formule cinglante : « Turns out it only costs you 600 BTC to ignore an email from the red team » (il s’avère qu’il ne coûte que 600 BTC d’ignorer un e-mail de la red team), rapporte Bitcoin.com News.

Blockstream conteste. Samson Mow, ancien directeur de la stratégie de l’entreprise, a nié tout e-mail ignoré et estimé que les insinuations de la Red Team « diminuaient le professionnalisme » du collectif. De son côté, le fondateur de Blockstream, Adam Back, a attribué le bug à « an incorrect bug fix, to an AI-found bug which was also a non-critical bug » (un correctif erroné, apporté à un bug détecté par IA et jugé non critique). Calle a rétorqué que ces déclarations étaient inexactes et incomplètes, et promis de publier son propre récit détaillé du processus de divulgation une fois que Blockstream aurait publié son post-mortem complet.

Peu importe, à ce stade, qui a raison sur les dates : le simple fait que la chronologie de la divulgation soit contestée en public illustre pourquoi la transparence est la colonne vertébrale d’un bon post-mortem. Quand chaque partie raconte une histoire différente, l’écosystème n’apprend rien ; il choisit un camp. Un post-mortem « blameless » et vérifiable, avec les horodatages des courriels et des commits déposés noir sur blanc, aurait éteint la polémique au lieu de l’alimenter. C’est le paradoxe : plus un incident est technique, plus sa résolution finit par se jouer sur la confiance.

Qui paie l’ardoise ?

Restait la question la plus concrète : qui absorbe les quelque 40 millions d’euros manquants ? Adam Back a répondu que Blockstream couvrirait la parité 1 pour 1 entre le L-BTC et le bitcoin, épongeant le déficit pour que les détenteurs de L-BTC soient rendus entiers, selon Crypto Times. À l’heure où nous écrivons, le bitcoin s’échange autour de 66 000 euros (CoinGecko), ce qui laisse la ligne comptable ouverte tant que les 598,5 BTC restent dans la nature.

C’est un choix lourd de sens. Dans un système fédéré, la promesse implicite est que le peg tient : un L-BTC vaut toujours un BTC. Laisser le déficit aux utilisateurs aurait cassé cette promesse et, avec elle, la raison d’être de la sidechain. En couvrant le trou, Blockstream protège la confiance, mais transforme un bug technique en perte d’entreprise.

C’est la même logique économique que l’on retrouve partout où un intermédiaire garantit un actif adossé : la question n’est jamais seulement « qui a été piraté », mais « qui a promis de rendre entier ». On la retrouve, sous d’autres formes, dans l’économie des ETF Bitcoin, où les frais rémunèrent précisément la garde et la garantie opérationnelle. Un post-mortem honnête devrait toujours répondre à cette question de l’ardoise, car elle conditionne la survie de la confiance bien plus que le détail cryptographique.

Anatomie comparée : Bybit, Coldcard, Drift, Liquid

Pour mesurer ce qui fait un bon post-mortem, il faut comparer. Voici quatre incidents majeurs récents, très différents par leur vecteur, et le retour d’expérience qui a suivi.

Chacun raconte une histoire différente. Le post-mortem de Bybit, publié par l’éditeur du portefeuille Safe avec le concours de Mandiant, est souvent cité en exemple : il retrace précisément comment le groupe Lazarus a détourné des jetons de session AWS d’un développeur pour injecter du JavaScript malveillant sur l’interface app.safe.global, en ciblant spécifiquement les signataires de Bybit, détaille Cointelegraph. Le cas Coldcard, analysé par TRM Labs, montre une faille de 2021 refaisant surface cinq ans plus tard : un générateur d’aléa affaibli ramenait l’entropie de certaines graines de 128 à parfois 40 bits, les rendant brute-forçables sans jamais toucher l’appareil. Quant à Drift, son post-mortem détaille une infiltration patiente de six mois attribuée à la Corée du Nord, où les attaquants ont joué le rôle d’un fonds de trading crédible pendant des mois avant de frapper.

Ces quatre récits ont un point commun : les meilleurs post-mortems ne se contentent pas de décrire le « comment », ils exposent le « pourquoi ça a mis si longtemps ». C’est le test décisif de l’honnêteté.

Ce que 2026 nous apprend : les clés, pas le code

Mis bout à bout, ces incidents dessinent une année charnière. TRM Labs a recensé plus de 200 attaques sur le premier semestre 2026, pour près d’un milliard de dollars dérobés ; CertiK avance un chiffre plus élevé, autour de 1,32 milliard. Surtout, la répartition a changé : les compromissions d’infrastructure représentent une minorité d’incidents mais l’écrasante majorité des montants perdus.

Le message pour les équipes est double. D’abord, auditer le code ne suffit plus ; il faut auditer les humains, les processus de signature, la chaîne d’approvisionnement logicielle et les accès. Ensuite, la qualité de la réponse compte autant que la prévention. Un protocole qui publie vite un post-mortem honnête, coordonne le déploiement d’un correctif et communique clairement limite la contagion. À l’inverse, l’opacité nourrit la panique et la spéculation.

Le fait que des sociétés d’audit comme CertiK soient elles-mêmes entrées en bourse et scrutées par Wall Street ne fait qu’augmenter la pression sur la rigueur de ces analyses. Un rapport d’incident bâclé n’est plus seulement une faute morale ; c’est un risque réputationnel, parfois boursier. Paradoxalement, cette exposition pourrait pousser l’industrie vers de meilleurs post-mortems, à condition que la transparence ne devienne pas un simple argument marketing.

Audité, et quand même piraté

L’incident Liquid rappelle une vérité inconfortable : un logiciel peut être open source, audité et éprouvé, et receler malgré tout une faille latente pendant des années. Le cache de rangeproofs n’était pas un morceau de code obscur ; c’était une optimisation de performance dans un projet scruté par certains des cryptographes les plus pointus du secteur. La faille n’était pas dans la cryptographie « difficile », mais dans la plomberie « facile » qui l’entoure. Le diable, comme toujours, s’était logé dans un détail d’implémentation.

C’est une leçon que les investisseurs et les utilisateurs devraient graver : le label « audité » n’est pas un talisman. Il réduit le risque, il ne l’annule pas. Cette confusion entretient d’ailleurs tout un marché de la réassurance de façade, jusqu’aux faux audits, où un badge de sécurité usurpé sert d’appât. Un vrai audit est une photographie à un instant t ; un vrai post-mortem, lui, est la vidéo de ce qui s’est passé quand la photographie a menti.

Et l’AMF dans tout ça ?

Pour un lecteur francophone, une question se pose : qu’aurait à dire un régulateur comme l’Autorité des marchés financiers (AMF) sur un tel épisode ? Liquid, en tant que protocole, n’est pas un acteur régulé en France. Mais les plateformes qui l’utilisent, elles, peuvent l’être. Depuis l’entrée en application du règlement MiCA fin 2024 et du règlement DORA (résilience opérationnelle numérique) le 17 janvier 2025, les prestataires de services sur crypto-actifs et les entités financières agréées doivent maintenir une gestion des risques informatiques et notifier les incidents majeurs à leur autorité de tutelle.

Il faut distinguer deux objets que l’on confond souvent. Le post-mortem technique, public, sert l’écosystème : il explique la faille pour que d’autres ne la répètent pas. La notification réglementaire, elle, est confidentielle et obligatoire : elle vise à protéger les clients et la stabilité du marché. Les deux convergent, mais ne se substituent pas l’un à l’autre. Un acteur français exposé à Liquid via ses réserves aurait dû, en théorie, déclencher une notification DORA en interne bien avant qu’un rapport public ne circule.

Cette exigence de traçabilité s’inscrit dans un calendrier réglementaire européen chargé, que nous suivons dans notre compte à rebours de la semaine décisive de septembre 2026. La tendance de fond est claire : la culture du post-mortem, longtemps informelle et volontaire, se rapproche peu à peu d’une obligation réglementaire. Pour les acteurs européens, bien documenter un incident n’est plus seulement une bonne pratique ; cela devient une condition de conformité.

La checklist du bon post-mortem

Que retenir, concrètement ? Pour une équipe, un bon post-mortem se reconnaît à quelques signes. Il arrive vite, mais pas trop vite : les faits d’abord, les conclusions ensuite. Il nomme la cause racine sans jargon défensif. Il distingue ce qui a été perdu de ce qui a été récupéré. Il propose des actions datées et attribuées, pas des intentions vagues. Et il assume les erreurs humaines en les convertissant en garde-fous techniques.

• Un résumé clair et une chronologie horodatée en UTC.
• Une cause racine unique, nommée, distincte des facteurs aggravants.
• Un impact chiffré : fonds perdus, fonds récupérés, utilisateurs touchés.
• Des mesures d’urgence et un plan de remédiation avec responsables et échéances.
• Une posture « blameless » : chaque erreur humaine devient une barrière automatique.
• Une divulgation coordonnée du correctif, pour éviter le scénario du N-day.

Pour un utilisateur, les enseignements sont plus simples encore. Ne jamais confondre « audité » et « sûr ». Se méfier des sidechains et des ponts, qui concentrent la valeur et multiplient les surfaces d’attaque. Et lire les post-mortems : ils sont, avec les rapports on-chain, la meilleure éducation gratuite qui soit sur les risques réels d’un actif. Le cas Liquid restera comme un rappel que même le camp le plus rigoureux de Bitcoin n’est pas à l’abri d’une ligne de code trop optimiste, et que la manière dont on raconte la catastrophe compte presque autant que la catastrophe elle-même.

Frequently Asked Questions

Qu’est-ce qu’un post-mortem d’exploit en crypto ?

Un post-mortem d’exploit est un rapport d’incident publié après un piratage. Il décrit ce qui a cassé, la cause racine, le montant perdu, les mesures prises et le plan pour éviter la récidive. Un bon post-mortem est « blameless », horodaté en UTC et assorti d’actions datées et attribuées.

Combien le Liquid Network a-t-il perdu en septembre 2026 ?

L’attaquant a créé près de 3 998 L-BTC frauduleux, puis retiré environ 4 000 BTC de la réserve fédérée, soit à peu près 265 millions d’euros au cours du moment. Environ 3 400 BTC ont été renvoyés ; il restait près de 598,5 BTC, quelque 40 millions d’euros, que Blockstream a refusé de racheter.

Le hack de Liquid venait-il de clés volées ?

Non. Contrairement à la majorité des vols de 2026, il ne s’agissait pas de clés privées compromises mais d’un bug de code : une collision de clé dans le cache de vérification des rangeproofs du logiciel Elements, qui laissait passer des preuves invalides.

Pourquoi Blockstream a-t-il refusé de payer la « prime » du hacker ?

Parce que prélever des fonds puis exiger un paiement pour les rendre relève, selon l’entreprise, du vol et non de la divulgation responsable. Blockstream a jugé qu’accepter créerait un précédent dangereux et a préféré couvrir lui-même la parité L-BTC/BTC pour ses utilisateurs.

Comment reconnaître un bon post-mortem ?

Il arrive rapidement, nomme une cause racine sans jargon défensif, chiffre l’impact, sépare les pertes des fonds récupérés et propose des actions concrètes avec responsables et échéances. Il privilégie une divulgation coordonnée du correctif pour ne pas offrir de carte aux attaquants.

Par la rédaction sécurité de HOGE Wire.