Des bitcoins et des litecoins ont été volés dans des portefeuilles chauds hébergés sur des serveurs BTCPay Server en version 2.4.1 ou antérieure. Selon l’avis officiel publié le 2 novembre 2026, une simple mise à jour ne suffit pas pour ces serveurs : il faut repartir d’un serveur neuf avec un nouveau portefeuille. Les fonds dont les clés sont gardées hors du serveur, notamment sur un portefeuille matériel, n’ont pas été touchés. Voici ce qu’il faut vérifier maintenant.

1. Les faits, datés

• Les vols. Le 1er novembre 2026, le projet BTCPay Server a reçu des signalements de vols de bitcoins et de litecoins dans des portefeuilles chauds, c’est-à-dire des portefeuilles dont les clés de dépense sont stockées sur le serveur lui-même (avis BTCPay Server, 02.11.2026).
• Les versions visées. Les attaques ont ciblé les serveurs en version 2.4.1 (publiée le 23 juillet 2026) ou antérieure. Les attaquants ont exploité, par une autre méthode, la vulnérabilité corrigée dans la version 2.4.2, publiée le 7 août 2026 (avis BTCPay Server, 02.11.2026).
• La chronologie (heures UTC). Le 1er novembre, une vidange de portefeuille a eu lieu à 13 h 46 ; le premier e-mail signalant un vol est arrivé à 20 h 56 ; à 22 h 25, le projet a demandé sur X aux opérateurs d’éteindre leurs serveurs. Des hébergeurs, dont LunaNode, ont mis des instances hors ligne par précaution. Le projet précise ne pas savoir quand l’exploitation a commencé (avis BTCPay Server, 02.11.2026).
• Les versions récentes. Pour les serveurs déjà en 2.4.2 ou plus récente au moment de l’alerte du 1er novembre, le projet dit n’avoir constaté aucun impact (avis BTCPay Server, 02.11.2026).
• Ce que l’on ignore. Le nombre de victimes et le montant volé n’ont pas été publiés. BTCPay Server étant auto-hébergé, le projet explique n’avoir aucun moyen de suivre ses utilisateurs (Cointelegraph, 02.11.2026). Les soldes des adresses de destination signalées ne doivent pas être lus comme un total des pertes, selon l’avis.

2. Première vérification : votre version

Connectez-vous à votre instance : le numéro de version s’affiche en bas de la page. Trois cas, selon l’avis officiel :

• Vous étiez déjà en 2.4.2 ou plus récente avant l’alerte du 1er novembre : aucun impact constaté par le projet. Restez à jour.
• Vous êtes en 2.4.1 ou antérieure, ou vous avez mis à jour depuis l’une de ces versions après l’alerte du 1er novembre : le projet recommande fortement de migrer vers un serveur neuf avec un nouveau portefeuille, même si vous n’avez constaté aucun vol.
• Des fonds ont disparu ou vous voyez des signes d’accès non autorisé : considérez la machine entière et tous ses secrets comme compromis, et suivez la même procédure, même si vous avez déjà mis à jour.

Un solde inchangé ne prouve rien : l’avis rappelle qu’il n’exclut pas une intrusion antérieure, et qu’une mise à jour ne retire pas un accès déjà obtenu par un attaquant.

3. Deuxième vérification : avez-vous un portefeuille chaud sur le serveur ?

Dans BTCPay Server, un portefeuille est « chaud » quand sa clé privée ou sa phrase de récupération a été créée ou importée sur le serveur, ce qui permet au serveur de dépenser seul. C’est le cas des portefeuilles « hot wallet » créés par l’assistant de configuration, et en pratique de tout nœud Lightning hébergé sur la même machine. À l’inverse, si vous avez seulement fourni une clé publique étendue (xpub) ou connecté un portefeuille matériel, le serveur peut générer des adresses et suivre les paiements, mais il ne peut pas dépenser.

Selon l’avis, les fonds des portefeuilles dont les clés de dépense sont gardées hors du serveur, y compris les portefeuilles matériels, n’ont pas été affectés. Attention toutefois : la recommandation de reconstruire un serveur ancien s’applique aussi dans ce cas, car l’attaquant a pu accéder au reste de la machine.

4. La procédure recommandée par l’avis

1. Créer un nouveau portefeuille et y transférer les fonds restants du portefeuille chaud, depuis un appareil de confiance et avec une nouvelle phrase de récupération. Réutiliser l’ancienne seed sur un nouveau serveur laisse ces fonds exposés.
2. Mettre l’ancien serveur hors ligne, en conservant les journaux et les historiques de transactions utiles à l’enquête.
3. Installer une machine virtuelle neuve avec la dernière version prise en charge de BTCPay Server, depuis des sources de confiance, et y connecter le nouveau portefeuille. Ne restaurez pas l’ancien serveur en entier sur la nouvelle machine.
4. Remplacer tous les mots de passe et clés d’accès que l’ancien serveur pouvait connaître : hébergement, SSH, application, API, Lightning. Depuis un appareil de confiance, jamais sur l’ancienne machine.

Si votre serveur est géré par un hébergeur, le projet vous invite à le contacter pour la migration. En cas de vol, écrivez à security@btcpayserver.org en indiquant la version utilisée, la date de votre dernière mise à jour, le moment de la découverte (avec votre fuseau horaire) et les identifiants de transaction publics. N’envoyez jamais de phrase de récupération, de clé privée ni de mot de passe. Et déposez plainte auprès des autorités de votre pays (avis BTCPay Server, 02.11.2026).

5. Encaisser sans garder : la configuration en lecture seule

BTCPay Server sait fonctionner sans jamais détenir vos clés. Vous créez le portefeuille sur un portefeuille matériel ou sur un appareil hors ligne, puis vous ne donnez au serveur que la clé publique étendue (xpub, ou zpub selon le format). Le serveur dérive une nouvelle adresse pour chaque facture et détecte les paiements, mais il n’a rien à signer. Les fonds arrivent directement sur des adresses que vous seul pouvez dépenser.

C’est d’ailleurs la pratique que l’avis officiel recommande pour recevoir des paiements. Si un portefeuille chaud vous est indispensable au quotidien, par exemple pour des remboursements ou pour Lightning, le projet conseille de n’y laisser que le montant nécessaire et de déplacer régulièrement le reste vers un portefeuille dont les clés sont hors du serveur.

Gardez en tête qu’une xpub n’est pas un secret anodin : elle ne permet pas de dépenser, mais elle révèle toutes vos adresses et donc votre historique de paiements. Un serveur compromis reste donc un problème de confidentialité, même sans perte de fonds.

6. La leçon générale : un serveur de paiement devrait encaisser, pas garder

Un serveur exposé sur Internet est par nature une cible. Il tourne en permanence, accepte des connexions du monde entier et dépend de mises à jour régulières. Y stocker des clés de dépense revient à laisser la recette de la journée dans la caisse enregistreuse, porte ouverte, pendant la nuit. Le rôle d’un serveur de paiement est de recevoir et de constater ; le rôle de garder revient à des clés que vous contrôlez, idéalement hors ligne.

Deuxième leçon : les mises à jour de sécurité ne sont pas optionnelles. La faille exploitée ici était corrigée depuis le 7 août 2026, près de trois mois avant les vols. Le projet invite à suivre ses annonces de nouvelles versions sur X et sur son groupe Telegram, en soulignant la hausse des attaques automatisées.

Cela n’enlève rien à la valeur de BTCPay Server : c’est un logiciel libre, sans intermédiaire ni frais de plateforme, qui permet à des commerçants d’accepter le bitcoin en restant souverains. Son équipe a d’ailleurs publié un avis détaillé et transparent, en reconnaissant qu’elle aurait dû faire davantage pour alerter les utilisateurs de versions anciennes. L’auto-hébergement demande simplement de la maintenance. Si vous ne pouvez pas l’assurer, des solutions gérées existent ; la boutique de bitcoinvalais.ch utilise par exemple Swiss Bitcoin Pay. Chaque option a ses compromis, à évaluer selon vos besoins et votre capacité à maintenir un serveur.

En résumé

• Vérifiez la version affichée en bas de votre interface BTCPay Server.
• En 2.4.1 ou antérieure : serveur neuf, nouveau portefeuille avec nouvelle seed, nouveaux accès. Mettre à jour ne suffit pas.
• Pour encaisser, préférez une xpub dont les clés restent sur un portefeuille matériel.
• Gardez le moins possible sur un portefeuille chaud et installez les mises à jour dès leur sortie.

Sources

• BTCPay Server, « Security Incident Affecting BTCPay Server 2.4.1 and Earlier », 02.11.2026
• Cointelegraph, « BTCPay Server Identifies Attack Vector After Bitcoin Wallet Theft Reports », 02.11.2026

Cet article est informatif et ne constitue pas un conseil financier ou technique personnalisé. En cas de doute, référez-vous à l’avis officiel du projet.