En onze jours, Bitcoin a perdu plus d’argent à cause de défaillances logicielles que lors de toute faillite de plateforme d’échange depuis 2022. Pendant quatre ans et demi, un portefeuille matériel a généré des phrases de récupération à partir d’un générateur de nombres aléatoires défectueux. Un serveur de paiement a livré à des attaquants les identifiants de nœuds Lightning. Un service d’échange a cessé ses activités parce qu’il n’arrivait plus à corriger ses systèmes aussi vite qu’on les attaquait. Aucun de ces incidents n’était une défaillance du protocole : Bitcoin a chaque fois exécuté exactement les instructions reçues. Ce sont les logiciels auxquels les gens confient la tâche de communiquer avec Bitcoin en leur nom qui ont failli, et cette distinction est capitale lorsque vous détenez vous-même vos clés.
Voici les faits, dans l’ordre où ils se sont produits, ainsi que les mesures précises exigées par chaque incident. Si vous exploitez un nœud, un portefeuille ou un serveur marchand, au moins une des sections ci-dessous s’adresse directement à vous.
Coldcard : quatre ans et demi de phrases de récupération faibles
Coinkite a révélé le 30 juillet 2026 que, dans certaines versions, le micrologiciel Coldcard générait les phrases de récupération à partir de la mauvaise source d’aléa. La cause tient à une seule ligne de logique du préprocesseur C. Le micrologiciel vérifiait #ifndef MICROPY_HW_ENABLE_RNG, ce qui demande si un symbole est défini, et non s’il est vrai. Or, la configuration de la carte le définissait comme (0) : défini, mais nul. Le test réussissait, le générateur matériel de nombres aléatoires était contourné et la génération de la phrase de récupération basculait silencieusement vers le générateur pseudo-aléatoire Yasmarang de MicroPython, initialisé avec bien moins d’entropie que ne l’exige une clé Bitcoin.
Conséquence concrète : une robustesse effective d’environ 40 bits sur les appareils Mk2 et Mk3, et d’environ 72 bits sur les Mk4, Mk5 et Q, alors qu’une phrase de récupération de 12 mots est censée offrir 128 bits. Quarante bits ne représentent pas une faiblesse théorique. C’est une fin de semaine de calcul.
Le défaut remonte à une version du micrologiciel publiée en mars 2021. Coinkite l’a corrigé le 31 juillet 2026, un jour après sa divulgation. Voici le point essentiel, trop souvent relégué au second plan : le correctif ne peut pas réparer une phrase de récupération déjà générée. L’entropie est consommée au moment de la création. Un appareil qui a produit une phrase faible en 2022 et qui a été consciencieusement mis à jour depuis protège encore aujourd’hui une phrase faible. Le seul remède consiste à créer un nouveau portefeuille avec un micrologiciel corrigé, puis à y transférer les fonds.
La bonne question diagnostique n’est donc pas « quel micrologiciel est installé actuellement? », mais bien « quel micrologiciel était installé le jour où cette phrase de récupération a été créée? » Ce sont deux questions différentes, aux réponses différentes, et seule la seconde permet de savoir si vous êtes exposé.
Les pertes sont considérables et le décompte se poursuit. Galaxy Research a confirmé le 8 août le vol de 1 719 BTC, soit environ 111 millions de dollars, et estime que les pertes totales pourraient atteindre 2 055 BTC, ou quelque 130 millions de dollars. Le vol n’est pas l’œuvre d’un seul groupe : les analystes ont recensé au moins quinze attaquants indépendants, plus de vingt-cinq modes d’attaque distincts et trois vagues. Environ 90 % des bitcoins volés n’ont pas bougé depuis. Aucun identifiant CVE n’a été publié. Aucun autre fabricant de portefeuilles matériels n’a été touché : Trezor, Ledger, Jade et Passport ont tous déclaré ne pas être concernés, et ces déclarations demeurent valides.
Nous avons publié un avis complet dès que l’affaire a éclaté, notamment pour vous aider à déterminer votre niveau d’exposition et à effectuer la migration : consultez notre avis sur la vulnérabilité des phrases de récupération Coldcard. Si vous avez déjà généré une phrase de récupération sur un Coldcard, lisez-le avant de poursuivre sur cette page.
BTCPay Server : des identifiants, pas des bitcoins
Le 7 août 2026, BTCPay Server a publié un avis de sécurité et lancé la version 2.4.2. La vulnérabilité permettait à un attaquant distant non authentifié d’obtenir les fichiers d’identifiants .macaroon de LND. Un macaroon est le jeton au porteur qui autorise l’exécution de commandes sur un nœud Lightning. Quiconque le détient peut contrôler le nœud et déplacer ses fonds. L’attaquant n’avait besoin ni d’un mot de passe, ni d’une session, ni d’un accès préalable à la machine : les identifiants étaient accessibles de l’extérieur.
La faille a été découverte et divulguée de manière responsable par Craig Raw, le développeur de Sparrow Wallet. L’avis de BTCPay ne laisse aucun doute sur la suite : « Nous avons confirmé que des attaquants ont exploité cette vulnérabilité. Des utilisateurs ont été touchés et des fonds ont été volés. » Foundation, l’entreprise derrière les portefeuilles matériels Passport, et Citadel21 ont tous deux vu leurs nœuds Lightning vidés avant la publication de l’avertissement. Ce détail résume à lui seul la divulgation moderne : la fenêtre entre la rédaction d’un correctif et l’arrivée de l’attaque se mesure désormais en heures, et les défenseurs qui se sont retrouvés du mauvais côté de cette fenêtre n’avaient commis aucune faute.
Toutes les versions antérieures à la 2.4.2 sont touchées, y compris les versions candidates de la 2.4.2. Les portefeuilles sur la chaîne ne sont pas exposés par cette faille; seuls les déploiements LND divulguent leurs identifiants.
Si vous exploitez BTCPay Server avec LND, la mise à jour seule ne suffit pas. C’est le point que les exploitants risquent le plus de mal comprendre :
- Mettez à jour immédiatement — Réglages du serveur → Maintenance → Mettre à jour. Vérifiez que le pied de page de l’administration indique la version 2.4.2 et que LND affiche la version 0.21.1.
- Comprenez ce que la mise à jour ne fait pas. La version 2.4.2 ferme la brèche, mais n’invalide pas les identifiants déjà volés. Un macaroon exfiltré la semaine dernière fonctionne encore sur un serveur à jour, à moins d’avoir été remplacé.
- Renouvelez vos macaroons. Cette opération se fait automatiquement lors de la mise à niveau vers la version 2.4.2; vérifiez qu’elle a bel et bien eu lieu.
- Auditez le nœud. Examinez l’historique des transactions, les fermetures de canaux et les soldes sur la chaîne afin de repérer toute activité que vous n’avez pas autorisée.
- Renouvelez tout autre identifiant exposé. Si LND est accessible par un mandataire inverse externe ou un service caché Tor, renouvelez également ces identifiants.
- Retirez les fonds de tout portefeuille chaud sur la chaîne généré par BTCPay et transférez-les vers un portefeuille dont les clés n’ont jamais été présentes sur le serveur touché.
- Si vous ne pouvez pas effectuer la mise à jour immédiatement, mettez le serveur hors ligne. Un serveur marchand hors ligne vous coûte des ventes. Un serveur vulnérable en ligne peut vous coûter le nœud.
Nous recommandons depuis longtemps BTCPay autohébergé comme moyen souverain d’accepter Bitcoin, et c’est toujours le cas : nos guides sur BTCPay autohébergé et BTCPay avec WooCommerce demeurent pertinents. Avec l’autohébergement, le résultat vous appartient, pour le meilleur comme pour le pire. Posséder sa propre infrastructure de paiement, c’est aussi assumer son calendrier de correctifs. Cette semaine, la facture est arrivée.
Boltz : l’arrêt qui devrait vous inquiéter le plus
Le 3 août 2026, Boltz a suspendu pour une durée indéterminée son service d’échange non dépositaire. Aucun fonds n’a été perdu : le service est non dépositaire par conception, et cette architecture a tenu bon. Ce qui a cédé, c’est la capacité de l’équipe à suivre le rythme.
Boltz a évoqué des mois de sondages automatisés de son infrastructure, assistés par l’IA, et expliqué son arrêt en termes simples : « Les attaquants itèrent maintenant plus vite qu’une équipe de notre taille ne peut trouver et corriger les failles. » En quelques heures, Aqua, Bull Bitcoin et Zeus ont perdu les fonctions d’échange fournies par Boltz.
Relisez cette citation, car il s’agit de la phrase la plus importante de cet article. Coldcard était un bogue resté inconnu pendant quatre ans. BTCPay était un bogue découvert par un chercheur de bonne foi. Boltz représente quelque chose de nouveau : une équipe compétente, dotée d’une architecture solide, qui a fermé un service fonctionnel parce que le rythme des attaques entrantes dépassait sa capacité d’intervention. Personne n’a vaincu son modèle de sécurité. L’équipe a simplement été distancée.
Voilà ce qui change lorsque les outils d’attaque deviennent automatisés et peu coûteux. La contrainte qui limitait autrefois l’exploitation était l’attention d’humains qualifiés, une ressource rare et chère. Lorsque cette contrainte disparaît, chaque petite équipe qui maintient une infrastructure Bitcoin — et presque toute cette infrastructure repose sur de petites équipes — affronte un adversaire qui ne dort jamais, ne se lasse jamais et ne coûte que quelques dollars par heure.
Ce qui relie réellement ces trois incidents
Il serait tentant de classer ces événements comme trois bogues sans rapport survenus durant un mauvais mois. Ce serait une erreur.
Bitcoin est l’actif le plus intrinsèquement numérique jamais créé. Il n’existe ni rétrofacturation, ni service antifraude, ni tribunal capable d’annuler une transaction confirmée. Tous les autres systèmes financiers comportent une couche humaine qui absorbe les erreurs après coup. La finalité de Bitcoin — la propriété même qui justifie qu’on le détienne — fait qu’un défaut logiciel se transforme directement et irréversiblement en valeur volée. Cela a toujours été vrai. C’est vrai depuis 2009.
La nouveauté réside dans le coût nécessaire pour trouver le défaut. Un bogue de génération aléatoire faible comme celui de Coldcard est précisément le genre de chose qu’une machine peut rechercher inlassablement dans le code, alors que le regard d’un réviseur humain peut passer dessus : une directive de préprocesseur subtilement et discrètement erronée, dans un fichier que personne n’a eu besoin d’examiner depuis 2021. L’économie de l’audit s’est inversée : une recherche qui exigeait auparavant un mois de travail spécialisé peut maintenant être réalisée en un après-midi par un banc d’essai bien configuré.
Cette capacité peut servir les deux camps, et le reste de cette série porte sur celui qui saura le mieux l’exploiter. Les attaquants l’ont obtenue les premiers, comme c’est généralement le cas. La riposte défensive — une initiative bénévole appelée Bitcoin Red Team, qui a mobilisé seize chercheurs et un banc d’essai d’IA conçu sur mesure pour examiner 390 dépôts Bitcoin en un seul sprint — fait l’objet du deuxième article de cette série. Ce que cette équipe a rencontré en demandant l’accès aux laboratoires d’IA de pointe est abordé dans le troisième article; c’est la partie de cette histoire qui, ailleurs, n’a pas été racontée correctement.
Votre liste de vérification
Si vous ne retenez que l’essentiel :
- Avez-vous déjà généré une phrase de récupération sur un Coldcard? Déterminez la version du micrologiciel utilisée le jour où cette phrase a été créée. Si elle précède le correctif du 31 juillet 2026, transférez vos fonds vers un portefeuille généré sur un appareil digne de confiance. Commencez par notre avis.
- Exploitez-vous BTCPay Server avec LND? Passez à la version 2.4.2, confirmez que le renouvellement des macaroons a bien eu lieu, auditez vos canaux et videz tout portefeuille chaud généré par BTCPay.
- Exploitez-vous une infrastructure Bitcoin autohébergée? Abonnez-vous à ses avis de sécurité par un canal que vous consultez réellement. Dans les cas de Boltz et de BTCPay, quelques heures, et non quelques jours, ont séparé l’exploitant protégé de celui dont les fonds ont été vidés.
- Détenez-vous des bitcoins sur du matériel auquel vous n’avez pas pensé depuis des années? Les événements de ce mois-ci justifient de réévaluer périodiquement cette décision. Un micrologiciel écrit en 2021 protège encore des fonds en 2026.
Rien de tout cela ne constitue un argument contre l’auto-garde. C’est un argument en faveur d’une auto-garde entretenue, comme toute machine que vous possédez et exploitez. Nous réparons du matériel de minage pour gagner notre vie, et la défaillance que nous observons le plus souvent n’est pas celle d’une machine mal conçue. C’est celle d’une machine que personne n’a vérifiée pendant quatre ans.
