Les attaquants ont passé la journée de vendredi à vider discrètement les nœuds Lightning liés à BTCPay Server, le processeur de paiements bitcoin auto‑hébergé, après que le projet a confirmé qu’une vulnérabilité critique de BTCPay Server était activement exploitée. Le fabricant de portefeuilles matériels Foundation et le zine bitcoin Citadel21 ont tous deux signalé des nœuds vidés, quelques heures avant que l’avertissement public de BTCPay ne soit publié. L’incident, révélé le 7 août 2026, a forcé les commerçants, les plateformes d’échange et les backends de portefeuilles utilisant le logiciel à se précipiter pour appliquer un correctif alors même que les vols étaient encore en cours.
Summary
Points clés à retenir
- BTCPay Server a confirmé une vulnérabilité critique, activement exploitée, et a publié la version 2.4.2 pour la corriger le 7 août 2026.
- Le fabricant de portefeuilles matériels Foundation et le zine bitcoin Citadel21 ont tous deux vu leurs nœuds Lightning vidés, avec des canaux fermés de force et des fonds drainés.
- Le fondateur Nicolas Dorier a indiqué que le bug n’a été découvert que parce qu’un développeur, Craig Raw de Sparrow Wallet, a perdu des fonds et analysé les journaux — et non via des audits assistés par IA.
- BTCPay est auto‑hébergé, ce qui signifie qu’il n’y a pas d’opérateur central pour appliquer le correctif au nom des utilisateurs ; chaque propriétaire de serveur doit mettre à jour individuellement.
- Les utilisateurs sont invités à régénérer les macaroons et les fichiers de crédentiels après la mise à jour, car des identifiants volés peuvent encore donner accès même après l’update.
Vulnérabilité critique exploitée dans les nœuds Lightning de BTCPay Server
Le problème central est simple mais grave : une faille dans BTCPay Server a permis aux attaquants d’atteindre et de vider les nœuds Lightning sans avoir besoin de compromettre séparément le portefeuille chaud de l’utilisateur. BTCPay a publié un avis urgent à 11 h 51 (heure de l’Est) déclarant : « Il existe une vulnérabilité critique actuellement exploitée sur BTCPay Server, qui peut entraîner une perte de fonds. » Le projet a demandé aux commerçants de mettre à jour immédiatement ou d’éteindre leurs serveurs s’ils ne pouvaient pas appliquer le correctif sur‑le‑champ. Ce message aurait dépassé 550 000 vues en moins de cinq heures, signe de la rapidité avec laquelle l’alerte s’est propagée dans la communauté des paiements bitcoin.
Vue d’ensemble de l’incident et publication du correctif
Dorier, le fondateur de BTCPay, a publié la version 2.4.2 le même matin avec un avertissement sans détour en tête des notes de version : « Cette version contient la correction d’une vulnérabilité critique qui est activement exploitée. Vous devez mettre à jour aussi vite que possible. » Il a également été demandé aux intégrateurs de mettre à niveau NBXplorer, le backend de suivi de portefeuilles de BTCPay, vers la version 2.6.10. La version limite en outre le taux de création de factures publiques sur les demandes de paiement et marque neuf méthodes de contrôleur réparties sur cinq fichiers comme non routables, fermant ainsi des endpoints qui étaient accessibles par HTTP par accident.
Utilisateurs affectés et détails de l’impact
Selon Zach Herbert, directeur général de Foundation (société productrice du portefeuille matériel Passport), son nœud avait déjà disparu avant qu’il ne voie l’alerte. « Notre nœud Foundation a été vidé pendant la nuit par des attaquants », a‑t‑il écrit, précisant ensuite que seul le nœud Lightning utilisé pour le traitement des paiements avait été touché — le portefeuille chaud de l’entreprise n’a pas été affecté, mais « tous les canaux ont été fermés et les fonds ont été balayés ». hodlonaut, le commentateur pseudonyme derrière Citadel21, a signalé le même schéma, écrivant que le nœud Lightning du zine « venait d’être vidé », tout en notant qu’il n’y avait pas de montants significatifs en jeu. Au moins un autre opérateur a décrit dans les réponses à l’avertissement de BTCPay des canaux fermés et des soldes drainés. Ni Herbert ni hodlonaut n’ont divulgué de montants exacts, et aucun décompte global des nœuds affectés ou du total de bitcoins perdus n’a été publié.
Découverte et nature de la vulnérabilité
Cette faille n’a pas été détectée par un scan automatisé — elle n’est apparue qu’après que quelqu’un s’est fait voler. Ce détail est important car il met en lumière un décalage entre la façon dont les outils de sécurité de bitcoin sont censés fonctionner et la manière dont ce bug particulier a réellement été découvert.
Découverte menée par un développeur vs audits IA
Dorier a attribué à Craig Raw, le développeur derrière Sparrow Wallet, le mérite d’avoir reconstitué ce qui se passait après que ses propres fonds ont été affectés. « Nous avons eu une chance incroyable qu’un développeur soit impacté et puisse analyser les logs pour comprendre ce qui se passait », a écrit Dorier. « D’une certaine manière, cela n’a pas été trouvé par des scans IA, mais par le fait qu’il a perdu de l’argent. » Cet aveu est notable étant donné que le Bitcoin Red Team — un groupe de bénévoles que BTCPay a remercié pour la divulgation — avait passé la semaine précédente à effectuer des audits assistés par IA sur l’ensemble de la stack open source bitcoin. Dorier a confirmé que les scans du groupe ont manqué ce bug spécifique. « Le rapport IA que nous avons reçu de la red team ne contenait pas celui‑ci », a‑t‑il déclaré. « Mais ce bug était vraiment sournois, je ne suis pas surpris qu’un simple scan ne l’ait pas trouvé, ou l’ait considéré comme à faible risque. »
Précisions sur les différences entre les bugs
BTCPay n’a pas détaillé quelle faille les attaquants ont exploitée, mais Dorier a été explicite : il ne s’agit pas du contournement de l’authentification à deux facteurs déjà mentionné dans le changelog du projet. Après qu’un utilisateur a publié une explication générée par IA attribuant l’attaque à ce bug divulgué, Dorier a rectifié : « Ce bug a été trouvé par la Red team, ce n’est pas la vulnérabilité critique en question. » Le contournement 2FA divulgué affectait Greenfield, l’API de BTCPay, et a été corrigé le 4 août — il permettait d’accéder à des comptes protégés par une application d’authentification avec seulement un e‑mail et un mot de passe, même si l’écran de connexion du navigateur appliquait correctement la 2FA en permanence. Un rapport technique complet sur la vulnérabilité actuellement exploitée est encore en attente. Le contributeur principal Uncle Rockstar a indiqué que l’équipe « travaille avec le Bitcoin Red Team pour traiter entièrement les détails de la vulnérabilité et publiera prochainement un article technique détaillé ».
Défis opérationnels et étapes de remédiation
Appliquer le correctif logiciel ne représente que la moitié du travail — et ce partage des responsabilités met en évidence une faiblesse structurelle dans la façon dont l’infrastructure bitcoin auto‑hébergée est sécurisée.
Responsabilité de mise à jour pour les logiciels auto‑hébergés
Parce que BTCPay est auto‑hébergé, il n’existe aucun opérateur central capable de déployer un correctif sur toutes les installations en une seule fois. Chaque commerçant, plateforme d’échange et portefeuille utilisant le logiciel doit appliquer la mise à jour sur sa propre machine — et dans ce cas, les vols étaient déjà en cours avant que la plupart des utilisateurs ne voient l’avertissement. Il s’agit d’un compromis fondamental de l’infrastructure auto‑hébergée : elle supprime un point de défaillance unique pour la censure ou l’arrêt, mais elle implique aussi qu’un correctif critique ne protège que les opérateurs qui agissent assez vite pour l’installer.
Rafraîchissement des identifiants et risques de sécurité persistants
Mettre à jour le logiciel ne referme pas automatiquement la porte derrière un attaquant qui est déjà entré. BTCPay a invité les utilisateurs à effectuer un rafraîchissement complet des macaroons et du fichier macaroons.db — les fichiers de crédentiels qui permettent l’accès à un nœud Lightning LND — ainsi qu’à renouveler les chaînes d’authentification pour les autres backends Lightning. Toute personne ayant généré un portefeuille chaud on‑chain à l’intérieur de BTCPay a été invitée à déplacer ces fonds et à recréer le portefeuille à partir de zéro. Kaloudis, un représentant du portefeuille ZEUS basé sur LND, a résumé le risque de manière claire : « Ne supposez pas que vous êtes en sécurité après la mise à jour. » Des macaroons volés survivent à une mise à jour logicielle, ce qui signifie qu’un attaquant qui a copié les identifiants avant le correctif conserve l’accès au nœud jusqu’à ce que ces fichiers soient détruits et réémis — ce qui correspond à ce que les victimes ont décrit : des canaux fermés de force et des soldes vidés, plutôt que le serveur lui‑même compromis une seconde fois.
Contexte des récents échecs de sécurité de l’infrastructure Bitcoin
Cette alerte n’est pas arrivée isolément. Elle est survenue au neuvième jour de ce qui s’annonce comme l’une des périodes les plus difficiles pour la sécurité de l’infrastructure bitcoin de mémoire récente, et ce timing soulève une question plus large : les outils conçus pour détecter ces bugs suivent‑ils le rythme des logiciels qui sont déployés ?
Incidents parallèles dans le matériel et les services Bitcoin
Un bug de firmware Coldcard de 2021, qui faisait passer la génération de seed par un randomiseur logiciel faible, a vidé environ 114 $ millions en BTC depuis le 30 juillet, touchant plus de 5 200 adresses, certaines victimes signalant la perte de leurs économies de toute une vie. Puis, le 3 août, le pont de swap Boltz a suspendu son service pour une durée indéterminée, déclarant que les attaquants « itèrent désormais plus vite qu’une équipe de notre taille ne peut trouver et corriger ». La vulnérabilité de BTCPay Server est le troisième échec de sécurité significatif à frapper l’infrastructure adjacente à bitcoin en moins de deux semaines.
Limites des audits du Bitcoin Red Team
Le Bitcoin Red Team s’est lui‑même formé en réaction directe à l’incident Coldcard, et ses premiers résultats ont été substantiels : Calle, qui aide à diriger le groupe, a indiqué que 16 chercheurs ont déposé 4 962 constats sur 390 projets en seulement 27,5 heures, dont 85 problèmes critiques et 635 de gravité élevée. Pourtant, les scans assistés par IA du groupe ont manqué le bug exact qui est maintenant exploité contre les utilisateurs de BTCPay — un manque que Dorier a reconnu directement. Cet échec souligne un défi plus large pour l’industrie : les outils de sécurité automatisés peuvent produire du volume, mais les bugs sournois au niveau de la logique peuvent encore nécessiter un humain, parfois quelqu’un qui a déjà perdu de l’argent, pour repérer ce qu’un scan néglige.
Le bitcoin lui‑même n’a montré aucune réaction à tout cela. L’actif se négociait autour de 64 800 $ vendredi après‑midi, en hausse de 0,7 % sur 24 heures et de 2,6 % sur la semaine, selon CoinGecko — un rappel que les échecs de sécurité au niveau de l’infrastructure dans l’écosystème bitcoin ne font pas nécessairement bouger le prix de l’actif autour duquel ils sont construits, même lorsque les pertes sont réelles et non résolues.
FAQ
Quel était le principal problème avec BTCPay Server le 7 août 2026 ?
Une vulnérabilité critique était activement exploitée, permettant aux attaquants de vider les nœuds Lightning des utilisateurs, ce qui a conduit BTCPay à publier un correctif urgent et à demander aux opérateurs de mettre à jour immédiatement ou d’éteindre leurs serveurs.
Qui comptait parmi les victimes spécifiques affectées par la vulnérabilité de BTCPay Server ?
Parmi les victimes notables figuraient le fabricant de portefeuilles matériels Foundation, dont le nœud de paiement lié à Passport a été vidé pendant la nuit, et le zine bitcoin Citadel21, dont le nœud Lightning a été vidé avec ses canaux fermés de force.
La vulnérabilité exploitée est‑elle la même que le contournement de l’authentification à deux facteurs divulgué plus tôt ?
Non. Le fondateur de BTCPay, Nicolas Dorier, a précisé que le bug activement exploité est différent et sans lien avec le contournement de l’authentification à deux facteurs déjà divulgué dans le changelog du projet et corrigé le 4 août.
Que doivent faire les utilisateurs de BTCPay Server après avoir appliqué le correctif ?
Les utilisateurs doivent régénérer les macaroons et les fichiers de crédentiels, car des identifiants volés peuvent survivre à une mise à jour logicielle et continuer à donner aux attaquants un accès non autorisé aux nœuds Lightning même après l’application du correctif.
{« @context »: »https://schema.org », »@type »: »FAQPage », »mainEntity »:[{« @type »: »Question », »name »: »Quel était le principal problème avec BTCPay Server le 7 août 2026 ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Une vulnérabilité critique était activement exploitée, permettant aux attaquants de vider les nœuds Lightning des utilisateurs, ce qui a conduit BTCPay à publier un correctif urgent et à demander aux opérateurs de mettre à jour immédiatement ou d’éteindre leurs serveurs. »}},{« @type »: »Question », »name »: »Qui comptait parmi les victimes spécifiques affectées par la vulnérabilité de BTCPay Server ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Parmi les victimes notables figuraient le fabricant de portefeuilles matériels Foundation, dont le nœud de paiement lié à Passport a été vidé pendant la nuit, et le zine bitcoin Citadel21, dont le nœud Lightning a été vidé avec ses canaux fermés de force. »}},{« @type »: »Question », »name »: »La vulnérabilité exploitée est-elle la même que le contournement de l’authentification à deux facteurs divulgué plus tôt ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Non. Le fondateur de BTCPay, Nicolas Dorier, a précisé que le bug activement exploité est différent et sans lien avec le contournement de l’authentification à deux facteurs déjà divulgué dans le changelog du projet et corrigé le 4 août. »}},{« @type »: »Question », »name »: »Que doivent faire les utilisateurs de BTCPay Server après avoir appliqué le correctif ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Les utilisateurs doivent régénérer les macaroons et les fichiers de crédentiels, car des identifiants volés peuvent survivre à une mise à jour logicielle et continuer à donner aux attaquants un accès non autorisé aux nœuds Lightning même après l’application du correctif. »}}]}
Article produit avec l’assistance de l’intelligence artificielle et relu par l’équipe éditoriale.
