Piratage BTCPay Server : que faire ?

Par Louis T. · Mis à jour le 03 novembre 2026

Le 1er novembre 2026, des commerçants qui encaissent en bitcoin avec BTCPay Server ont vu leur portefeuille chaud se vider vers une adresse inconnue. Le projet a identifié la cause le lendemain : tous les serveurs touchés tournaient sous la version 2.4.1 ou une version plus ancienne, alors que la faille exploitée était corrigée depuis la 2.4.2, publiée le 7 août. Bitcoin et litecoin ont été dérobés. Si votre boutique utilise BTCPay, la consigne de l'équipe va plus loin qu'une mise à jour : pour un serveur resté sous 2.4.1 ou avant, il faut repartir d'une machine neuve et d'un nouveau portefeuille, même si aucun vol n'a été constaté.

BTCPay Server est un logiciel libre que le commerçant installe sur son propre serveur, souvent un serveur virtuel (VPS) loué chez un hébergeur, pour accepter des paiements en bitcoin sans intermédiaire. Aucun tiers ne détient les fonds, donc personne ne peut rembourser à la place du commerçant quand le serveur est compromis.

Ce qui s'est passé, heure par heure

BTCPay a publié sa chronologie le 2 novembre. Les heures sont en UTC (ajoutez une heure pour Paris).

Date (UTC)	Événement
23 juillet	Sortie de la version 2.4.1, dernière version vulnérable
7 août	Version 2.4.2 : correction d'une faille critique, déjà exploitée contre des nœuds Lightning LND
Août à octobre	Série de mises à jour de sécurité, jusqu'à la 2.4.7 du 29 octobre
1er novembre, 13 h 46	Vidage d'un portefeuille décrit dans les signalements (la date du premier vol n'est pas établie)
1er novembre, 20 h 56	Premier e-mail de victime reçu par l'équipe
1er novembre, 22 h 25	Alerte publique sur X : éteignez vos serveurs. LunaNode et d'autres hébergeurs coupent les instances BTCPay de leurs clients par précaution
2 novembre	BTCPay désigne les versions 2.4.1 et antérieures et publie la procédure de reconstruction

Dans son communiqué, l'équipe reconnaît qu'elle aurait dû « faire davantage » pour joindre les utilisateurs restés sur d'anciennes versions. Trois mois se sont écoulés entre le correctif et les vols, et une partie des installations n'avait jamais été mise à jour.

Une faille d'août, exploitée autrement

En août, la faille corrigée par la 2.4.2 permettait à un attaquant non authentifié de récupérer à distance les fichiers « macaroon » de LND, les identifiants qui donnent le contrôle d'un nœud Lightning. Des fonds avaient été volés sur des nœuds LND. Après analyse, BTCPay avait alors écrit que ses portefeuilles on-chain, hot wallets compris, n'étaient pas concernés.

En novembre, ce sont justement ces portefeuilles on-chain qui ont été vidés. BTCPay explique que les attaquants ont utilisé « une méthode différente » pour exploiter la même faille, sans la détailler. Selon les premières constatations de son fondateur Nicolas Dorier rapportées par Bitcoin.com, l'attaquant a obtenu un accès administrateur aux serveurs. Le cabinet Ostorlab, qui a analysé les correctifs publics du 7 août, décrit une double cause : cinq fonctions internes du logiciel étaient exposées par erreur comme points d'accès web, et la configuration Docker standard rendait l'API de LND accessible depuis le nom de domaine public. Les correctifs de la 2.4.2 désactivent ces fonctions et retirent LND de la configuration publique.

Seuls les hot wallets ont été vidés, c'est-à-dire les portefeuilles dont les clés de dépense sont stockées sur le serveur. Les portefeuilles dont les clés sont ailleurs, par exemple sur un portefeuille matériel, n'ont pas été touchés.

Combien a été volé ?

BTCPay n'a donné ni montant total ni nombre de victimes. Il a publié deux adresses de destination, une en bitcoin et une en litecoin, en prévenant qu'une partie de leur activité est antérieure aux vols et que leurs soldes ne valent pas bilan des pertes.

La société d'analyse Bitquery, citée par The Cryptonomist, a relié 18,38 BTC et 3 405 LTC aux vols, soit environ 1,63 million de dollars. Elle compte 682 transferts entre le 30 octobre et le matin du 2 novembre, dont 87 % des fonds partis en une seule vague l'après-midi et le soir du 1er novembre. Après l'alerte de 22 h 25, 267 transferts supplémentaires ont encore emporté environ 150 000 dollars , sur des serveurs restés allumés malgré l'alerte.

Nous avons consulté les deux adresses le 3 novembre au soir (explorateurs mempool.space et BlockCypher). L'adresse bitcoin a reçu 20,33 BTC en 780 versements et n'en garde que 0,04 : le reste est déjà reparti. L'adresse litecoin a reçu environ 3 527 LTC et en conserve 3 507. Au cours du jour (69 315 € le BTC, 48,43 € le LTC selon CoinGecko), les montants retenus par Bitquery représentent environ 1,44 million d'euros.

Êtes-vous concerné ?

Pour connaître votre version, connectez-vous à BTCPay et regardez le bas de la page. Sur une installation Docker, la commande docker ps --format 'table {{.Names}}\t{{.Image}}' | grep -i btcpay affiche l'image utilisée ; une étiquette « latest » ne dit pas quelle version tourne réellement.

Votre situation	Ce que recommande BTCPay
Serveur déjà en 2.4.2 ou plus récent au moment de l'alerte du 1er novembre	Aucun impact constaté. Mettez quand même à jour vers la dernière version (2.4.7).
Serveur en 2.4.1 ou avant, sans vol constaté	Videz le hot wallet vers un nouveau portefeuille, puis passez sur un serveur neuf. Valable aussi si vous avez mis à jour après l'alerte.
Vol constaté ou signe d'accès non autorisé	Considérez la machine entière et tous ses secrets comme compromis, même si elle est à jour depuis.
Clés de dépense hors du serveur (portefeuille matériel)	Fonds non touchés. Le serveur reste à reconstruire s'il tournait sous 2.4.1 ou avant.

Un solde intact ne prouve rien, prévient BTCPay : l'attaquant a pu entrer plus tôt, et une mise à jour ne retire pas un accès déjà obtenu. Si vous êtes hébergé chez LunaNode ou un autre prestataire et que votre instance a été éteinte d'office, c'est lui qu'il faut contacter pour obtenir une machine neuve. Rien dans les communications de BTCPay ne concerne les clients qui ont payé une facture : les vols portent sur les fonds stockés sur le serveur du commerçant.

Repartir sur un serveur propre, étape par étape

La procédure ci-dessous reprend celle de BTCPay, dans l'ordre.

1. Créez d'abord un nouveau portefeuille sur un appareil de confiance avec une nouvelle phrase de récupération, puis transférez-y ce qui reste sur le hot wallet. Réutiliser l'ancienne phrase sur le nouveau serveur laisserait les fonds exposés.
2. Mettez l'ancien serveur hors ligne, mais gardez ses journaux et l'historique des transactions avant de le détruire : ils servent à l'enquête.
3. Créez une nouvelle machine virtuelle, installez la dernière version de BTCPay depuis les sources officielles et connectez-y le nouveau portefeuille. Ne restaurez pas une sauvegarde complète de l'ancien serveur.
4. Depuis un appareil sain, révoquez et remplacez tout ce que l'ancien serveur pouvait atteindre : compte chez l'hébergeur, clés SSH, clés d'API des plugins de boutique, identifiants Lightning. Ne tapez aucun nouvel identifiant sur l'ancienne machine.

Si vous avez été volé, écrivez à security@btcpayserver.org en indiquant la version utilisée, la date de votre dernière mise à jour, le moment où vous avez constaté le vol (avec votre fuseau horaire) et les identifiants de transaction. N'envoyez jamais de phrase de récupération, de clé privée ni de mot de passe, et nettoyez les journaux avant de les partager : un faux « support BTCPay » qui vous demanderait votre phrase serait une arnaque, comme celles décrites dans notre guide pour éviter les arnaques crypto. BTCPay demande aussi de porter plainte. Après le vol d'août, des soutiens du projet avaient promis une prime de 10 % des fonds récupérés, plafonnée à 3 BTC ; rien de tel n'a été annoncé pour l'instant pour les vols de novembre.

De la 2.4.2 à la 2.4.7 : ce qui change en migrant

Passer directement d'une 2.4.1 à la 2.4.7 fait franchir six versions d'un coup, et plusieurs ont modifié des réglages par défaut. Mieux vaut les connaître avant que la caisse ne refuse un paiement.

• 2.4.2 : l'API de LND n'est plus accessible par le domaine public. Un portefeuille externe comme Zeus ne peut plus se connecter à votre nœud par ce biais. LND passe en 0.21.1 et ses macaroons sont régénérés.
• 2.4.4 : Bitcoin Core passe de 29.2 à 31.1 et LND en 0.21.3, la prise en charge de Bitcoin Knots est retirée. Les paiements NFC sont désactivés par défaut, les factures à montant nul bloquées, et le plugin WHMCS cesse de fonctionner tant qu'il n'est pas passé en version 4.0.0 avec une nouvelle clé d'API Greenfield.
• 2.4.5 : la nouvelle commande btcpay-routes permet de rouvrir proprement l'accès Lightning externe pour ceux qui en ont besoin. Tor n'est plus installé d'office : si votre boutique a une adresse .onion, réactivez-le avec sudo btcpay-fragments add opt-add-tor.
• 2.4.7 (29 octobre) : 85 problèmes de sécurité corrigés d'un coup, dont 1 critique, 13 élevés, 52 moyens et 19 faibles. Selon Nicolas Dorier, les serveurs publics et de démonstration qui tournaient déjà en 2.4.7 n'ont pas été attaqués.

Pour une installation Docker standard, la mise à jour se lance depuis Server Settings, puis Maintenance, puis Update. Vérifiez ensuite le numéro affiché en bas de page. Si vous faites tourner votre propre nœud à côté de BTCPay, notre article sur la mise à jour d'un nœud Bitcoin Core détaille les vérifications à faire avant de changer de version.

Hot wallet ou clés hors du serveur ?

BTCPay propose deux façons d'encaisser. Avec un hot wallet, la phrase de récupération est stockée sur le serveur : pratique pour rembourser un client ou payer un fournisseur depuis l'interface, mais quiconque prend la main sur le serveur prend aussi l'argent. L'autre option consiste à connecter un portefeuille matériel, par exemple un Ledger : BTCPay ne reçoit que la clé publique étendue, qui lui sert à générer une adresse par facture, et ne peut rien dépenser. C'est la configuration que BTCPay recommande toujours pour recevoir les paiements, et celle qui a protégé les commerçants le 1er novembre. Notre comparatif des portefeuilles froids aide à choisir l'appareil.

Si votre activité exige un hot wallet, BTCPay conseille de n'y laisser que le fonds de roulement des opérations courantes et de transférer régulièrement le surplus vers un portefeuille dont les clés ne sont pas sur le serveur. Nicolas Dorier le formule autrement : n'y garder que ce qu'on peut se permettre de perdre. Un nœud Lightning, lui, a besoin de ses clés en ligne pour fonctionner, et les fonds engagés dans ses canaux sont exposés de la même façon. L'équipe annonce ses versions sur son compte X et sur son groupe Telegram, et donne la priorité aux correctifs de sécurité plutôt qu'aux nouvelles fonctionnalités « pour l'avenir proche ». S'abonner à l'un des deux évite de découvrir une faille trois mois trop tard.

L'affaire tombe la même semaine que le piratage record de Binance, mais le risque n'a rien de comparable : Binance a annoncé couvrir les pertes de ses clients ; avec un logiciel auto-hébergé, le commerçant est seul responsable de son serveur et de ses fonds. Cet article décrit un incident de sécurité, ce n'est pas un conseil en investissement.

Questions fréquentes