Le processeur de paiement Bitcoin BTCPay touché par des rapports de vol de portefeuilles chauds

Avertissement d'arrêt d'urgence de BTCPay Server

BTCPay Server a émis un avertissement d'arrêt d'urgence le 1er novembre 2026, suite à des rapports indiquant que des attaquants siphonnaient des bitcoins de portefeuilles chauds connectés à des serveurs de paiement auto-hébergés. Le fondateur, Nicolas Dorier, a lié les compromissions signalées à des versions antérieures à 2.4.2, tout en précisant que les serveurs publics exécutant la version 2.4.7 n'avaient pas été attaqués.

Contexte et implications

Cet avertissement est survenu seulement trois jours après qu'une refonte de sécurité assistée par IA ait corrigé 85 vulnérabilités, soulevant des questions sur les risques auxquels sont confrontés les opérateurs qui retardent les mises à jour logicielles. À environ 22h25 UTC le 1er novembre, le compte officiel de BTCPay Server a publié un avis urgent :

"Nous recevons des rapports de portefeuilles chauds sur les serveurs BTCPay étant vidés par des attaquants non autorisés."

Les opérateurs ont été instruits de fermer leurs instances en utilisant la commande ./btcpay-down.sh jusqu'à ce que les enquêteurs puissent établir ce qui s'était passé.

Analyse des vulnérabilités

Le contributeur principal, Uncle Rockstar Developer, a renforcé l'avertissement en déclarant :

"Ce n'est pas un exercice : fermez votre serveur BTCPay si vous avez un portefeuille chaud."

BTCPay Server est un logiciel open-source permettant aux commerçants d'accepter des paiements en bitcoin (BTC) sans dépendre d'un intermédiaire de paiement conventionnel. Les opérateurs peuvent héberger le logiciel eux-mêmes et gérer leur propre infrastructure de portefeuille. Cette indépendance s'accompagne de responsabilités.

État des investigations

Au moment de la publication, les développeurs n'avaient pas divulgué le montant total de bitcoins volés ni le nombre de commerçants affectés. L'alerte initiale n'a également fourni aucun compte rendu confirmé sur la manière dont les attaquants avaient d'abord pénétré dans les systèmes compromis. Nicolas Dorier a ensuite offert une explication plus précise, indiquant que les déploiements affectés exécutaient un logiciel antérieur à la version 2.4.2.

Les attaquants auraient obtenu un accès administrateur, avec des traces d'analyse forensique pointant vers des vulnérabilités présentes dans ces anciennes versions. Dorier a également précisé que les serveurs publics et de démonstration exécutant la version 2.4.7 n'avaient pas été attaqués, tempérant ainsi la possibilité que la dernière version d'urgence ait elle-même introduit la compromission signalée.

Conséquences et réflexions

Le projet avait précédemment abordé une vulnérabilité distincte en août, qui permettait à des attaquants non authentifiés d'obtenir des identifiants de macaroon du Lightning Network Daemon (LND). Ce défaut a été corrigé dans la version 2.4.2. Les développeurs avaient précédemment déclaré que les portefeuilles on-chain de BTCPay n'étaient pas exposés par cette vulnérabilité spécifique.

Il n'a pas été établi de manière concluante si les derniers vols impliquaient la même faiblesse, une autre faille plus ancienne ou plusieurs faiblesses. Le timing ajoute une autre dimension à la situation. Le 29 octobre, BTCPay Server a publié la version 2.4.7 après avoir reçu des rapports de vulnérabilités générés par l'initiative de scan de sécurité open-source d'Anthropic.

Cette publication a corrigé 85 problèmes, dont un critique, 13 de haute gravité, 52 de gravité moyenne et 19 de faible gravité. L'incident BTCPay illustre une distinction critique entre la découverte de vulnérabilités et la protection des logiciels déployés.

Conclusion

Des entreprises, y compris Coincards, ont mis hors ligne leurs installations BTCPay suite à l'avertissement. Pour les commerçants, l'interruption crée un compromis immédiat entre la disponibilité des paiements et la protection des fonds accessibles via des portefeuilles connectés. Dorier a réitéré l'importance de limiter les soldes des portefeuilles chauds à des montants que les opérateurs peuvent se permettre de perdre.

Aucun estimé de perte définitif, nouveau correctif spécifique à l'incident ou feu vert n'avait été annoncé dans les mises à jour fournies. Les développeurs préparaient une explication plus complète. La question troublante va au-delà de BTCPay : alors que les systèmes d'IA accélèrent la découverte de vulnérabilités, l'infrastructure de paiement opérée indépendamment peut-elle suivre le rythme des correctifs ?