Mis à jour le 3 novembre 2026.
BTCPay Server a identifié les versions 2.4.1 et antérieures comme les cibles des vols sur hot wallets signalés le 1er novembre. Dans son avis du 2 novembre, le projet recommande une nouvelle machine et un nouveau wallet aux exploitants concernés, même s’ils ont entre-temps mis à jour leur logiciel.
La distinction est essentielle : corriger une vulnérabilité ne retire pas automatiquement l’accès qu’un attaquant aurait déjà obtenu. Un solde inchangé n’exclut pas une compromission antérieure. La réponse dépend donc de la version exécutée lors de l’alerte, et pas seulement de celle affichée aujourd’hui.
BTCPay Server : quelles installations sont concernées
L’avis officiel du 2 novembre désigne les serveurs exécutant la 2.4.1, publiée le 23 juillet, ou une version antérieure. Selon l’équipe, les attaquants ont utilisé une autre méthode pour exploiter une vulnérabilité corrigée dans la 2.4.2 du 7 août. Ce n’est pas présenté comme une faille du protocole Bitcoin.
Pour les serveurs qui exécutaient déjà la 2.4.2 ou une version ultérieure au moment de l’alerte du 1er novembre, le projet indique n’avoir observé aucun impact de ces attaques. Cette conclusion concerne l’enquête décrite ; elle ne garantit pas l’absence de toute autre vulnérabilité ou d’un risque futur.
| Situation | Indication du projet |
|---|---|
| 2.4.2 ou ultérieure avant l’alerte | Aucun impact observé de ces attaques |
| 2.4.1 ou antérieure | Nouveau serveur et nouveau wallet, même sans vol visible |
| Ancienne version mise à jour après l’alerte | La recommandation de reconstruction demeure |
| Vol ou accès non autorisé | Considérer la machine et les secrets accessibles comme compromis |
Mettre à jour n’est pas assainir une machine compromise
Une mise à jour corrige le code distribué par le projet. Elle ne démontre pas qu’un mot de passe dérobé est devenu inutilisable, qu’une session abusive est terminée ou que chaque composant de l’ancienne machine reste fiable. Confondre prévention et récupération peut laisser subsister un accès déjà obtenu.
La recommandation n’est donc pas de restaurer intégralement l’ancien serveur sur une nouvelle machine. L’équipe demande un environnement neuf, un logiciel maintenu et des identifiants remplacés. Cela ne signifie pas effacer indistinctement les preuves : les journaux pertinents et les références des transactions doivent être conservés avant le remplacement pour les besoins de l’enquête.
Hot wallets et clés de dépense hors du serveur
Un hot wallet conserve sur le serveur les clés permettant de dépenser. Dans le cas décrit, l’accès à cette machine peut donc avoir des conséquences directes sur les fonds. Notre explication des wallets custodial et non custodial distingue contrôle des clés, connexion et responsabilité opérationnelle.
Le projet précise que ces vols n’ont pas affecté les fonds dont les clés de dépense étaient conservées hors du serveur, notamment sur des hardware wallets. Cela ne rend pas une ancienne installation fiable au seul motif qu’elle utilise un dispositif de signature externe. La recommandation de reconstruire l’ancien serveur reste valable dans cette configuration.
Un nouveau wallet doit utiliser un nouveau secret
La séquence officielle commence par la création d’un wallet sur un appareil fiable, avec une nouvelle seed, puis le transfert des fonds encore présents dans le hot wallet. Réutiliser l’ancienne seed sur la nouvelle machine maintient ces fonds à risque si le secret a été exposé. Nouvelle adresse de réception et nouveau secret indépendant ne sont pas nécessairement équivalents.
Notre article sur la seed phrase et sa protection développe cette différence. Il ne faut pas saisir l’ancien secret sur un site de récupération ni l’envoyer à une personne proposant son aide. L’avis interdit explicitement de transmettre phrases de récupération, clés privées, mots de passe et autres identifiants, y compris à l’équipe de sécurité.
Après la protection des fonds restants et la conservation des preuves, le projet demande de mettre l’ancien serveur hors ligne et de préparer une machine virtuelle propre. Les identifiants potentiellement exposés doivent être révoqués et remplacés depuis un appareil fiable. Saisir leurs remplaçants sur la machine suspecte annulerait la séparation recherchée.
La version 2.4.7 ne modifie pas l’historique d’exposition
Conserver une copie pour l’enquête n’est pas la remettre en production. Avant de remplacer l’environnement, il faut préserver les éléments de récupération nécessaires et éviter de perdre leur unique exemplaire. Cela ne rend pas sûrs les identifiants ou la seed potentiellement exposés.
Les notes officielles de la 2.4.7, publiée le 29 octobre, décrivent d’autres correctifs de sécurité, de fiabilité et de comptabilisation des paiements. Elles permettent d’identifier la mise à jour disponible, mais ne prouvent pas qu’une machine restée vulnérable jusqu’en novembre n’a jamais été visitée auparavant.
La publication d’une version et la réponse à un incident répondent à deux questions : quel code installer et comment traiter un environnement déjà suspect. Pour un hébergement géré par un tiers, le projet invite à demander de l’aide au fournisseur pour migrer vers une nouvelle VM. Nous n’avons réalisé aucune mise à jour, aucun transfert ni aucun test sur les installations des lecteurs.
Les adresses publiées ne donnent pas un total certain des pertes
BTCPay Server publie des adresses de destination signalées, mais avertit que certaines opérations peuvent précéder les vols connus. Leurs soldes et historiques ne constituent donc pas un total confirmé des pertes. Nous n’attribuons pas chaque transaction à cet incident et ne présentons pas ces adresses comme une garantie de restitution.
Un signalement utile indique la version précédente, les horaires avec fuseau et les références publiques des transactions, après suppression des secrets dans les journaux. Si des fonds ont été volés, le projet recommande aussi une déclaration aux autorités locales. L’enjeu est d’établir l’exposition passée et de reconstruire la confiance dans l’environnement, pas simplement de constater un numéro de version récent.
