Des hot wallets vidés sur les instances BTCPay Server obsolètes poussent les marchands vers la 2.4.7

1er novembre 2026, soirée UTC. Les premiers signalements de vols arrivent au projet BTCPay Server. 2 novembre 2026, tôt le lundi. Le mainteneur annonce avoir « identifié un vecteur d’attaque ciblant les instances en version 2.4.1 (23 juillet 2026) ou antérieure ». 2 novembre 2026, toujours. Les opérateurs sont invités à passer en 2.4.7 ou à éteindre leur serveur. L’essentiel tient en une phrase : un attaquant qui obtient un accès administrateur sur une instance de paiement auto-hébergée vole les clés des hot wallets avec lui, et personne ne peut annuler un transfert Bitcoin.

Pour un marchand qui accepte la cryptomonnaie, ce n’est pas une alerte de plus. C’est la démonstration, chiffrée et datée, de ce que coûte un modèle où la mise à jour dépend de celui qui héberge le logiciel.

Ce qui s’est passé

BTCPay Server est un processeur de paiement open source et auto-hébergé : les commerçants acceptent Bitcoin, Litecoin et d’autres actifs directement dans leurs propres portefeuilles, sans intermédiaire de paiement ni frais de plateforme. Un hot wallet désigne un portefeuille dont les clés privées résident sur un serveur connecté. C’est la contrepartie d’un traitement automatique des factures : les fonds doivent pouvoir bouger sans intervention humaine.

Les vols ont commencé le soir du 1er novembre. Dès les premiers rapports, les opérateurs ont été invités à couper leurs serveurs en attendant une enquête, et le projet a demandé aux hébergeurs VPS de mettre hors ligne les instances concernées par précaution. Nicolas Dorier, fondateur du projet, a précisé que les attaques ne visaient pas les serveurs publics : l’enquête s’est concentrée sur la manière dont l’attaquant parvenait à se connecter en tant qu’administrateur sur des versions antérieures à la 2.4.2, sortie le 7 août.

Le projet a ensuite confirmé le diagnostic : l’attaquant exploitait des vulnérabilités présentes dans les versions antérieures à 2.4.2. Une fois administrateur, il pouvait déplacer les fonds des hot wallets directement.

La chronologie des versions qui compte

L’incident ne se comprend que si l’on remonte la chaîne des correctifs. Trois dates structurent l’exposition.

Le 23 juillet 2026, BTCPay Server 2.4.1 sort. C’est la version la plus récente encore vulnérable au vecteur exploité. Le 7 août 2026, la 2.4.2 corrige les failles qui permettent l’accès administrateur non autorisé. Un serveur qui reste sur 2.4.1 ou moins conserve donc une porte ouverte pendant près de douze semaines. Le 29 octobre 2026, le projet divulgue une vulnérabilité critique distincte, découverte via le scanner Frontier OSS d’Anthropic, ce qui déclenche la sortie d’urgence de la 2.4.7.

La séquence est instructive. La divulgation du 29 octobre a braqué les projecteurs sur le projet trois jours avant les vols, mais Dorier a été clair : les indices montrent que l’attaquant a utilisé des failles des versions antérieures à 2.4.2, pas la vulnérabilité d’octobre. Autrement dit, les victimes ne sont pas celles qui ont tardé trois jours à patcher, mais celles qui ont laissé passer douze semaines de mises à jour.

Le mainteneur a été sans ambiguïté : « Nous n’avons aucun signalement crédible de vol de hot wallet pour les utilisateurs de la dernière version 2.4.7. Nous exhortons à nouveau chacun à garder son BTCPay Server à jour. »

Pourquoi le self-hosting change tout

Le cœur de l’affaire n’est pas technique : c’est le modèle de distribution. Un processeur de paiement hébergé peut pousser un correctif ou révoquer un accès depuis un point central. Une instance BTCPay Server auto-hébergée n’a personne derrière elle pour le faire à sa place. Le fardeau du timing retombe entièrement sur le marchand, souvent une petite boutique sans équipe sécurité dédiée.

La demande adressée aux hébergeurs VPS de débrancher les serveurs vulnérables est inhabituelle pour un projet open source, qui n’a par définition aucun contrôle sur les serveurs que les commerçants exploitent eux-mêmes. Elle révèle le vrai problème : le mainteneur ne voit pas les versions déployées, et un vol de cryptomonnaie est irréversible. Contrairement à un virement bancaire, un transfert Bitcoin ne se rappelle pas — ce qui explique pourquoi le projet a préféré dire « éteignez tout » avant même de connaître la cause complète.

La leçon dépasse BTCPay Server. Toute application financière auto-hébergée — passerelle de paiement, portefeuille, nœud — transforme son opérateur en sa propre équipe de sécurité. Le montant total volé n’a pas été publié, et le nombre d’instances compromises non plus, ce qui empêche de mesurer l’ampleur réelle.

Ce qu’il faut faire maintenant

Les instructions du mainteneur sont précises et se résument à trois cas.

Si vous êtes en 2.4.1 ou antérieure, mettez l’instance hors ligne immédiatement. Le risque d’accès administrateur non autorisé rend toute autre action secondaire.

Pour une installation classique, mettez à jour via Paramètres du serveur → Maintenance → Mise à jour.

Pour un déploiement Docker, passez en ligne de commande :

sudo su -
cd btcpayserver-docker
./btcpay-update.sh

Les utilisateurs ayant subi des pertes sont invités à écrire à [email protected] et à signaler les vols aux autorités locales. Aucune figure de pertes n’a été communiquée, et le projet continue de recevoir des rapports d’incident.

Verdict

L’incident se juge moins à la faille qu’au délai : les versions vulnérables dataient de juillet, et le correctif 2.4.2 attendait depuis août. Si vous exploitez BTCPay Server, la règle est binaire — être en 2.4.7, ou éteindre. Si vous auto-hébergez un logiciel financier en général, retenez ceci : le correctif qui protège votre argent n’arrivera pas tout seul, et la fenêtre entre la sortie d’une version et son déploiement est votre responsabilité, pas celle du mainteneur. La cryptomonnaie ne pardonne pas le retard : une fois les clés du hot wallet parties, personne ne les ramène.

Références

• BleepingComputer — BTCPay Server warns of hot wallet crypto thefts on outdated instances (2 novembre 2026)
• BTCPay Server — Security incident: versions 2.4.1 and earlier
• BTCPay Server — Security advisory 2.4.2 (7 août 2026)
• Daily Security Review — BTCPay Server Hot Wallets Drained on Outdated Instances (3 novembre 2026)