Le 2 novembre 2026, BTCPay Server a demandé à ses opérateurs d’arrêter leurs instances pendant une enquête sur des portefeuilles chauds vidés par des attaquants non autorisés. Les premières informations visent les versions antérieures à 2.4.2, sans chiffrer les pertes ni le nombre de serveurs touchés.
🔑 En bref
- Le projet demande d’arrêter toutes les instances avec la commande btcpay-down.sh jusqu’à la fin de l’enquête.
- Le fondateur Nicolas Dorier cite des versions antérieures à 2.4.2 ; les serveurs publics, en 2.4.7, n’ont pas été attaqués.
- Un attaquant a obtenu des droits d’administrateur, sans que la méthode d’accès soit connue.
- Aucun montant volé, nombre de serveurs ou correctif n’a été communiqué à ce stade.
Une alerte sans montant ni périmètre confirmé
Dans un message publié sur X la veille, le projet a demandé aux exploitants d’arrêter leur instance si elle était active. Le texte, traduit de l’anglais, est sans équivoque sur la marche à suivre :
« Nous recevons des signalements de portefeuilles chauds sur des serveurs BTCPay Server qui sont vidés par des attaquants non autorisés. Si vous exécutez une instance, veuillez l’arrêter avec la commande btcpay-down.sh jusqu’à ce que nous terminions l’enquête. »
BTCPay Server, message publié sur X
Le message ne précisait ni le montant des fonds dérobés, ni le nombre de serveurs concernés. Il n’annonçait ni correctif, ni version précise, ni date de reprise. La consigne visait donc l’ensemble des installations, faute de périmètre établi. La commande arrête le logiciel BTCPay Server, que les exploitants doivent laisser désactivé pendant toute la durée de l’enquête.
BTCPay Server est un logiciel libre et auto-hébergeable qui permet aux commerçants de recevoir des paiements en bitcoin. Aucun intermédiaire de type custodial ne détient les fonds : chaque marchand héberge son instance, connecte ses portefeuilles et assume la sécurité de son infrastructure, notamment celle de ses serveurs exposés à Internet et de ses portefeuilles chauds.
Ce que dit le fondateur, deux heures plus tard
Environ deux heures après l’alerte initiale, Nicolas Dorier, fondateur du projet, a apporté des précisions. Selon lui, les signalements de vol « semblent concerner des versions de BTCPay Server antérieures à la version 2.4.2 ». Il a également indiqué qu’un attaquant s’était connecté avec un compte administrateur sur les serveurs visés, sans que l’équipe sache encore comment cet accès avait été obtenu.
« Les serveurs publics du projet, qui exécutent la version 2.4.7, n’ont pas été attaqués. »
Nicolas Dorier, fondateur de BTCPay Server
Cette déclaration porte uniquement sur les serveurs publics du projet. Elle ne signifie pas que toutes les installations en version plus récente ont été confirmées comme sûres. Aucun indicateur de compromission permettant à un opérateur de vérifier son instance n’a été publié.
Août 2026 : une faille déjà corrigée en 2.4.2
Un précédent incident avait été signalé le 7 août 2026. Le projet avait alors averti sur son compte X officiel qu’une « vulnérabilité critique est activement exploitée » sur BTCPay Server, pouvant entraîner une perte de fonds, et demandé d’installer immédiatement la version 2.4.2, qui contenait la mise à jour de sécurité requise.
Selon CoinDesk, la faille permettait à un attaquant externe de récupérer des fichiers d’identification de LND, le logiciel qui fait fonctionner un nœud du réseau Lightning. Avec ces fichiers, l’attaquant pouvait prendre le contrôle du nœud et déplacer ses fonds. La procédure indiquée aux administrateurs était la suivante :
- Ouvrir le tableau de bord d’administration.
- Accéder à Server, Maintenance and Update.
- Vérifier que le numéro de version affiché au pied de l’interface est bien 2.4.2.
- Arrêter le serveur si la mise à jour ne peut pas être appliquée immédiatement.
Au moment de l’alerte d’août, crypto.news relevait que BTCPay n’avait pas précisé quelles anciennes versions étaient vulnérables, comment les attaquants pénétraient les serveurs, combien de serveurs étaient compromis ni si des pertes avaient été confirmées. En novembre, l’évaluation provisoire vise en revanche les versions antérieures à 2.4.2. Ce changement de précision n’établit pas à lui seul une contradiction, d’autant que la nouvelle alerte concerne des signalements distincts. Les sources disponibles ne disent toutefois pas si les deux incidents reposent sur la même technique.
Portefeuilles chauds : une surface de risque structurelle
Le guide utilisateur officiel distingue plusieurs modes de réception. Avec un portefeuille chaud, la clé privée reste sur le serveur et la signature peut être automatisée à partir de la phrase de récupération conservée sur cette même machine. La documentation signale cette fonctionnalité par l’étiquette « DANGER » et précise qu’elle « s’accompagne d’implications de sécurité ».
« utiliser automatiquement la phrase de récupération conservée sur un serveur pour signer »
BTCPay Server, guide utilisateur officiel
Concrètement, un serveur compromis peut envoyer des fonds sans validation sur un autre appareil. La documentation indique d’ailleurs qu’un portefeuille chaud expose les fonds si le compte ou le serveur sont compromis. Le tableau suivant résume les trois configurations décrites par le guide :
| Configuration | Clé privée | Risque principal |
|---|---|---|
| Portefeuille chaud | Sur le serveur | Vol immédiat si le serveur est compromis |
| Portefeuille existant connecté | Hors du serveur | Exposition limitée aux données publiques |
| Portefeuille de surveillance | Absente du serveur | Signature requise via la phrase ou un signataire externe |
La connexion d’un portefeuille matériel ou logiciel existant est présentée comme le choix normal lorsque des fonds doivent être reçus dans un portefeuille déjà en service. Le guide recommande aussi d’activer l’authentification à deux facteurs, de conserver les codes de récupération hors ligne, de vérifier les adresses sur un appareil de confiance, de tester la récupération et la signature avant d’accepter des sommes importantes, et de ne jamais saisir une phrase de récupération existante sur un serveur connecté à Internet.
Cette architecture explique l’appel à l’arrêt manuel. Les utilisateurs gèrent leurs magasins et leurs portefeuilles, tandis que les opérateurs déploient les instances, entretiennent la base de données et les services réseau, réalisent les sauvegardes, appliquent les mises à jour et enquêtent sur les défaillances. Comme BTCPay ne sert pas d’intermédiaire de paiement, il n’existe aucun commutateur central permettant d’arrêter toutes les installations compromises : chaque hébergeur doit agir lui-même.
Version 2.4.0 et contexte de l’écosystème
La version 2.4.0, antérieure au correctif 2.4.2, avait introduit l’authentification sans mot de passe par clé d’accès, une procédure guidée de configuration des portefeuilles multisignatures, la saisie des clés de signature manuellement ou via BTCPay Server Vault, ainsi qu’une gestion plus fine des autorisations. L’API Greenfield permettait désormais de distinguer la consultation, la création, la signature et la diffusion des transactions. La même version mettait à jour LND de 0.19.3 à 0.21.0 bêta, Core Lightning de 25.05 à 26.06.1 et phoenixd de 0.6.3 à 0.8.0. Le billet de sortie signalait une incompatibilité des nouvelles versions de Core Lightning et de LND avec BTCPay Server 2.3.9 et recommandait de passer à la version 2.4.
Créé en 2017 par Nicolas Dorier, le logiciel était né d’un désaccord avec BitPay sur le fork SegWit et sur l’abandon de Bitcoin au profit de B2X. Selon STOKR, il peut être hébergé indépendamment, prend en charge les portefeuilles matériels et permet des paiements directs sans commissions de prestataire, mais laisse à chaque marchand la responsabilité de son serveur. Le guide de démarrage d’Elestio ne signale aucune instance hébergée touchée par les incidents.
Sur le plan plus large, le groupe volontaire Bitcoin Red Team a recensé 4 962 problèmes potentiels dans 390 projets liés à bitcoin, dont 720 classés graves ou critiques, sans identifier publiquement de faille critique non résolue. Aucun lien n’est établi avec les incidents BTCPay, et aucune réaction quantifiable du marché n’est rapportée : ni cours, ni volumes, ni montant agrégé des pertes.
Scénarios et points de vigilance
À la date des informations disponibles, la réponse opérationnelle consiste à arrêter toutes les instances avec la commande btcpay-down.sh et à les maintenir hors ligne jusqu’à la fin de l’enquête. L’instruction de mise à jour immédiate vers 2.4.2 concernait l’alerte d’août. Pour novembre, BTCPay n’a publié ni correctif, ni date de reprise, ni estimation des pertes, ni confirmation générale de sécurité des versions récentes.
Trois issues sont envisageables. Si l’enquête confirme une faille limitée aux versions antérieures à 2.4.2, la reprise pourra s’appuyer sur une mise à jour ciblée et la publication d’indicateurs de compromission. Si la méthode d’accès reste inconnue, le périmètre pourrait s’élargir au-delà des versions identifiées, ce qui prolongerait l’arrêt. Enfin, une intrusion liée à des identifiants volés ou à une mauvaise gestion des phrases de récupération rappellerait que la sécurité dépend autant des pratiques opérationnelles que du logiciel.
Pour les marchands, les priorités sont claires : vérifier la version installée, retirer toute phrase de récupération d’un serveur exposé et limiter le montant conservé dans un portefeuille chaud. L’ampleur réelle des fonds concernés reste inconnue à ce stade.
Sources
- CoinDesk, 2 novembre 2026
- Documentation utilisateur officielle BTCPay Server
- STOKR, présentation de BTCPay
- Elestio, guide de démarrage BTCPay
- Blog BTCPay Server, version 2.4.0
- crypto.news, alerte BTCPay Server d’août 2026
Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.
