BTCPay Server a averti les commerçants et les opérateurs de systèmes de paiement auto-hébergés qu’ils devaient mettre leurs serveurs hors ligne, après des signalements faisant état d’attaquants qui dérobaient des bitcoins dans des portefeuilles chauds connectés.
L’avis d’urgence, publié sur le compte officiel du projet vers 22 h 25 UTC le 1er novembre 2026, demandait aux opérateurs d’arrêter leurs instances BTCPay Server pendant que les développeurs enquêtaient sur les compromissions signalées.
L’incident soulève des inquiétudes pour les commerçants qui utilisent une infrastructure de paiement Bitcoin auto-hébergée afin d’éviter les intermédiaires de paiement traditionnels. Il met également en évidence un défi de sécurité pour les logiciels libres : un correctif de vulnérabilité ne protège que les installations qui reçoivent et appliquent effectivement la mise à jour.
Au moment des premiers signalements, les développeurs n’avaient pas confirmé la quantité de Bitcoin dérobée, le nombre de commerçants touchés ni la manière dont les attaquants avaient obtenu leur accès initial.
Les développeurs demandent aux opérateurs de mettre hors ligne les serveurs BTCPay
Le message d’urgence du projet signalait que des portefeuilles chauds connectés à des installations BTCPay Server étaient vidés par des attaquants non autorisés.
Il a été demandé aux opérateurs d’arrêter leurs instances à l’aide de la commande ./btcpay-down.sh, jusqu’à ce que les enquêteurs puissent déterminer l’ampleur et la cause de l’incident.
Le contributeur principal Uncle Rockstar Developer a renforcé l’avertissement, qualifiant la situation d’urgente et demandant aux opérateurs disposant de portefeuilles chauds d’arrêter leurs serveurs.
BTCPay Server est un logiciel de paiement open source qui permet aux commerçants d’accepter directement le Bitcoin, sans dépendre d’un prestataire de paiement traditionnel. Les entreprises peuvent héberger elles-mêmes le logiciel et conserver le contrôle de leur infrastructure de paiement et de leurs portefeuilles.
Ce modèle offre une plus grande indépendance opérationnelle, mais confie également à l’opérateur la responsabilité de la maintenance du serveur, des mises à jour logicielles et de la sécurité des portefeuilles.
Nicolas Dorier évoque d’anciennes versions du logiciel
Le fondateur de BTCPay Server, Nicolas Dorier, a ensuite partagé des conclusions préliminaires qui orientent l’enquête vers les anciennes installations.
Selon Dorier, les déploiements touchés utilisaient des versions antérieures à la 2.4.2. Les attaquants auraient obtenu un accès administrateur, et les traces médico-légales orientent vers des vulnérabilités présentes dans ces versions antérieures.
Dorier a également indiqué que les serveurs publics et de démonstration exécutant la version 2.4.7 n’avaient pas été attaqués.
Cette distinction est importante, car elle ne désigne pas la dernière version comme étant à l’origine des compromissions signalées. Toutefois, cette observation ne doit pas être interprétée comme la preuve que toutes les installations exécutant la version 2.4.7 sont à l’abri des attaques.
Les enquêteurs n’avaient pas encore publié d’explication technique complète. Le point d’entrée précis et le lien entre les vols signalés et les failles divulguées précédemment restaient donc indéterminés.
Une vulnérabilité antérieure du Lightning Network apporte un éclairage supplémentaire
L’enquête attire également l’attention sur un problème de sécurité distinct de BTCPay Server, divulgué en août.
Cette vulnérabilité permettait à des attaquants non authentifiés d’obtenir des identifiants macaroon de Lightning Network Daemon (LND). Ces identifiants servent de jetons d’autorisation donnant accès à certaines opérations du Lightning Network.
Les développeurs ont corrigé le problème dans la version 2.4.2. À l’époque, ils avaient indiqué que les portefeuilles on-chain propres à BTCPay Server n’étaient pas exposés par cette vulnérabilité particulière.
Il n’a pas été établi si les signalements de vols de portefeuilles en novembre sont liés à la même faille, à une autre vulnérabilité touchant les versions antérieures ou à une combinaison de problèmes de sécurité.
Cette distinction est importante. Une faille corrigée précédemment peut aider à expliquer l’exposition de déploiements obsolètes, mais elle ne peut être considérée comme la cause confirmée sans rapport d’expertise médico-légale publié.
La version 2.4.7 a corrigé 85 problèmes de sécurité trois jours avant l’incident
Le moment où l’avertissement d’urgence a été lancé a retenu davantage l’attention, car BTCPay Server avait publié une mise à jour majeure de sécurité trois jours plus tôt.
Le 29 octobre 2026, le projet a publié la version 2.4.7 à la suite de signalements de vulnérabilités générés dans le cadre de l’initiative d’analyse de sécurité open source d’Anthropic.
La mise à jour a corrigé 85 problèmes signalés, répartis comme suit :
1 critique
13 de gravité élevée
52 de gravité moyenne
19 de gravité faible
Ces découvertes sont survenues dans un contexte d’expansion plus large de la recherche de vulnérabilités assistée par l’IA. En 2026, des systèmes développés par Anthropic, OpenAI et Google ont démontré des capacités de plus en plus avancées pour identifier les faiblesses potentielles des logiciels.
L’initiative d’analyse d’Anthropic a signalé plus de 29 000 vulnérabilités potentielles en six mois, bien qu’une partie seulement ait fait l’objet d’un examen manuel.
L’incident de BTCPay Server illustre la différence entre la découverte de vulnérabilités et la sécurisation de logiciels déjà en production. Un projet peut publier des correctifs, mais les serveurs exploités indépendamment ne se mettent pas à jour automatiquement.
Une installation qui reste sur une ancienne version peut continuer d’exposer ses utilisateurs à des failles déjà corrigées par les développeurs.
Les commerçants mettent hors ligne leur infrastructure de paiement
L’avertissement a incité des entreprises, dont Coincards, à mettre hors ligne leurs installations BTCPay Server.
Pour les commerçants, cette décision implique un compromis opérationnel immédiat. Maintenir un serveur de paiement disponible permet d’assurer les transactions habituelles, mais laisser connecté un portefeuille chaud potentiellement compromis pourrait exposer les fonds à d’autres transferts non autorisés.
Dorier a également rappelé l’importance de limiter les soldes des portefeuilles chauds aux montants que les opérateurs peuvent se permettre de perdre.
Les portefeuilles chauds sont connectés à des systèmes en ligne et servent généralement aux transactions courantes. Leur accessibilité les rend pratiques pour le traitement des paiements, mais signifie aussi qu’ils nécessitent des mesures de sécurité rigoureuses et des limites sur les fonds qu’ils contiennent.
L’incident signalé a donc ravivé l’attention portée à l’exposition des portefeuilles, aux autorisations d’accès aux serveurs, aux pratiques de mise à jour et à la séparation des fonds opérationnels des réserves plus importantes.
Le défi plus large de la sécurité des paiements crypto auto-hébergés
Le modèle de BTCPay Server donne aux commerçants un contrôle direct sur les paiements en Bitcoin, mais l’auto-hébergement ne dispense pas d’une gestion continue de la sécurité.
Les opérateurs doivent surveiller les nouvelles versions des logiciels, appliquer les correctifs, protéger les identifiants d’administrateur et évaluer les risques associés aux portefeuilles connectés. Des mises à jour tardives peuvent laisser les systèmes exposés, même après la publication d’un correctif par les développeurs.
La recherche en sécurité assistée par l’IA pourrait accélérer la découverte et le signalement des vulnérabilités. Cela peut améliorer la sécurité des logiciels au fil du temps, mais exerce également une pression sur les responsables de la maintenance et les opérateurs, qui doivent examiner les découvertes, publier des correctifs et déployer rapidement les mises à jour.
Ce défi concerne particulièrement les infrastructures open source utilisées par des entreprises qui ne disposent pas nécessairement d’équipes dédiées à la sécurité. Il peut incomber aux commerçants individuels ou aux opérateurs de services d’appliquer un correctif.
L’enquête se poursuit, tandis que les pertes restent à confirmer
Les mises à jour disponibles ne comprenaient ni estimation confirmée du Bitcoin dérobé, ni décompte vérifié des commerçants touchés, ni compte rendu complet de la méthode d’attaque.
Les développeurs préparaient une explication plus détaillée, mais aucune information définitive sur un correctif propre à l’incident ni aucun feu vert n’avaient été annoncés dans les mises à jour fournies.
Tant que les enquêteurs n’auront pas publié davantage de détails, le lien entre les vols signalés, les anciennes versions du logiciel et les vulnérabilités divulguées précédemment restera hypothétique.
Publié initialement sur CryptosNewss.com