BTCPay Server : arrêter les serveurs auto-hébergés après vidage de hot wallets

L'équipe BTCPay Server a demandé aux opérateurs d'instances auto-hébergées d'arrêter leurs serveurs le 1er novembre 2026 après plusieurs signalements de hot wallets on-chain vidés par des attaquants non autorisés. L'alerte officielle est passée par le compte X de BTCPay Server, suivie environ deux heures plus tard par le message de Nicolas Dorier, fondateur du projet, qui circonscrit les signalements aux versions antérieures à 2.4.2 et indique que l'attaquant se connecte en administrateur sur les instances touchées. Reprise : Bitcoin.fr, CoinDesk.

Ce qu'il s'est passé

Le message BTCPay publié dimanche soir UTC est explicite : « Nous recevons des signalements de hot wallets sur des serveurs BTCPay qui sont vidés par des attaquants non autorisés. Si vous faites tourner une instance BTCPay, merci de l'arrêter (./btcpay-down.sh) jusqu'à la fin de notre investigation. » Le projet renvoie vers le script d'arrêt livré avec le déploiement Docker.

Deux heures plus tard, Dorier ajoute que les signalements concernent des « versions de BTCPay Server antérieures à 2.4.2 » et que les serveurs publics du projet, actuellement en 2.4.7 — version de la mise à jour d'urgence du 29 octobre 2026 — « n'ont pas été attaqués ». Le projet ne communique aucun montant volé, aucun décompte d'instances touchées et aucun CVE pour l'incident du 1er novembre. La seule précision sur la primitive d'attaque est que l'attaquant obtient un accès de niveau administrateur sur l'instance compromise ; la méthode d'obtention de cet accès reste à l'enquête.

Mécanisme — pourquoi un accès admin sur une build ancienne vide le hot wallet

La fonctionnalité hot wallet de BTCPay permet au commerçant de faire tourner un portefeuille dont la clé de signature est stockée sur le serveur lui-même, de sorte que le daemon signe les paiements sortants sans intervention humaine. La documentation du projet le rappelle sans détour : un hot wallet « peut signer automatiquement des paiements à l'aide d'une phrase mnémotechnique stockée sur le serveur », donc quiconque obtient un accès complet au serveur peut déplacer les fonds.

Deux fils relient l'alerte du 1er novembre à l'incident d'août 2026 sur le même projet, mais ce sont des primitives distinctes :

• La faille d'août a été corrigée en 2.4.2 et visait les credentials LND Lightning stockés sur le serveur. Elle permettait de dérober des macaroons et de vider des nœuds Lightning, pas les hot wallets on-chain créés dans BTCPay. L'article de CoinDesk du 8 août détaillait la primitive et les mitigations recommandées (rotation des macaroons, déplacement des fonds hors wallets exposés).
• Les signalements du 1er novembre portent sur des hot wallets on-chain, l'attaquant étant déjà en session admin. Primitive différente, compatible avec un opérateur jamais passé en 2.4.2 et qui traîne des credentials périmés, un reverse-proxy mal configuré ou un endpoint admin exposé — le projet n'a pas tranché, d'où la consigne d'arrêt total pendant le triage.

Les opérateurs déjà en 2.4.7 attendront la communication complète : Dorier écrit uniquement que les instances publiques dans cette version n'ont pas été touchées, pas que 2.4.7 est démontrée immunisée.

Que faire tout de suite

1. Arrêter l'instance avec ./btcpay-down.sh si le serveur fait tourner un hot wallet on-chain et que la version n'est pas confirmée à jour. La consigne du projet est claire.
2. Faire tourner les credentials admin et clés SSH sur l'hôte ; considérer la session administrateur qui a vidé le hot wallet comme persistante tant que l'inverse n'est pas prouvé.
3. Sortir les fonds des hot wallets des instances concernées. La seed sur disque est déjà compromise si le serveur l'était.
4. Auditer les logs de connexion — pages de statut, logs nginx et btcpay, provider 2FA le cas échéant, pour attribuer les sessions admin.
5. Attendre le post-mortem avant de redémarrer. Surveiller le compte X officiel BTCPay et le dépôt GitHub du projet.

Contexte — le motif sur l'outillage Bitcoin auto-hébergé

L'alerte du 1er novembre est le deuxième incident d'exploitation active sur BTCPay en trois mois. Notre couverture précédente du vidage LND d'août et de la prime communautaire est disponible sur ce site ; le motif commun est que les stacks commerçants auto-hébergées sont une cible prioritaire, et qu'un opérateur qui ne maintient pas de build récente hérite du risque empilé de chaque faille non corrigée. Les configurations hardware-wallet uniquement — où la clé de signature n'est pas sur le serveur — ne sont pas exposées à cette primitive de vidage, par construction. La documentation du projet le rappelle déjà ; l'incident du 1er novembre impose le choix.

Ce que les autres médias ont manqué

Plusieurs reprises présentent l'alerte du 1er novembre comme une « suite » de la faille d'août sur les macaroons LND. Les deux incidents partagent un projet et un profil de victime, mais les primitives diffèrent : août était un vol de credentials dans la stack Lightning, le 1er novembre est un abus de session administrateur contre la fonctionnalité hot wallet on-chain. Le message de Dorier trace la ligne (versions antérieures à 2.4.2 signalées, serveurs en 2.4.7 non touchés) ; les confondre masque qui est réellement exposé aujourd'hui.