BTCPay Server : des hot wallets Bitcoin vidés sur les instances non mises à jour, passez en 2.4.7

Ce qui s'est passé le 1er novembre 2026

BTCPay Server est le processeur de paiement Bitcoin open source le plus répandu en auto-hébergement : un commerçant l'installe sur son propre VPS Linux ou son serveur dédié pour encaisser des paiements en Bitcoin, en Litecoin ou sur le réseau Lightning sans intermédiaire. Le 2 novembre 2026, le projet a publié une alerte de sécurité (source : blog officiel BTCPay Server) : le 1er novembre, des hot wallets Bitcoin et Litecoin hébergés sur des instances BTCPay Server ont été vidés. Un hot wallet est un portefeuille dont la clé privée (la seed) est stockée sur le serveur lui-même, ce qui permet de dépenser les fonds depuis l'interface web. C'est précisément ce qui a permis aux attaquants de transférer les fonds une fois l'instance compromise.

La chronologie publiée par l'équipe (heures UTC) est serrée : premier transfert frauduleux identifié le 1er novembre à 13 h 46, premier signalement d'un utilisateur par e-mail à 20 h 56, demande aux hébergeurs VPS de couper les instances concernées dans la foulée, puis alerte publique sur X à 22 h 25 avec consigne d'éteindre les serveurs le temps de l'enquête. Le 2 novembre, l'investigation a établi que les instances touchées tournaient toutes en version 2.4.1 (publiée le 23 juillet 2026) ou antérieure. Le projet a aussi précisé n'avoir reçu aucun signalement crédible de vol sur une instance en 2.4.7, la version courante (annonce relayée par BleepingComputer).

Le projet n'a pas publié de montant total. Il a listé une adresse Bitcoin et une adresse Litecoin vers lesquelles les fonds ont été transférés, en avertissant que leur solde inclut des mouvements antérieurs aux vols signalés et ne constitue donc pas un total confirmé. Selon Nicolas Dorier, fondateur du projet, l'attaquant s'est connecté avec un compte administrateur sur des instances antérieures à la 2.4.2. Les portefeuilles matériels et les portefeuilles externes au serveur n'ont pas été touchés.

Versions affectées : la faille était corrigée depuis le 7 août

Le point le plus important de l'alerte tient en une phrase : la vulnérabilité exploitée en novembre est celle que la version 2.4.2 a corrigée le 7 août 2026, utilisée cette fois par une autre méthode. Le bulletin de sécurité 2.4.2 décrivait déjà une faille critique, exploitée en conditions réelles, qui permettait à un attaquant distant non authentifié de récupérer les fichiers .macaroon d'un noeud Lightning LND et d'en vider les canaux. En août, les portefeuilles on-chain n'étaient pas concernés. En novembre, ce sont les hot wallets Bitcoin et Litecoin qui ont été ciblés : même faille, autre chemin d'exploitation, et trois mois pendant lesquels les instances non mises à jour sont restées exposées.

Résumé des versions publiées depuis l'été, d'après les notes de version du dépôt GitHub de BTCPay Server :

Autrement dit, une instance en 2.4.2 ou plus récente au moment de l'alerte du 1er novembre n'a subi aucun impact constaté. Mais la 2.4.7 corrige à elle seule un problème critique et treize de sévérité élevée : rester sur une 2.4.2 ou une 2.4.5 n'a aucun sens. La cible, c'est la dernière version, et elle le restera à chaque nouvelle release.

Vérifier la version de votre instance BTCPay Server

La méthode officielle est la plus simple : connectez-vous avec un compte administrateur, le numéro de version s'affiche en bas à droite du pied de page de l'interface. Si vous ne voyez pas « 2.4.7 », vous avez du retard.

Si vous administrez plusieurs serveurs ou que vous voulez vérifier sans ouvrir l'interface, l'API Greenfield renvoie la version dans le champ version de l'endpoint /api/v1/server/info, avec une clé API :

curl -s -H "Authorization: token VOTRE_CLE_API" https://btcpay.exemple.fr/api/v1/server/info

Sur un déploiement Docker, le tag de l'image en cours d'exécution donne la même information depuis le terminal SSH :

docker ps --format "{{.Names}} {{.Image}}" | grep btcpayserver

Sur une installation manuelle (bare metal), le tag Git du dépôt compilé fait foi :

cd ~/src/btcpayserver && git describe --tags

Dans tous les cas, si le résultat est 2.4.1 ou inférieur, ne vous contentez pas de mettre à jour : lisez la section sur le redéploiement plus bas, car le projet considère ces serveurs comme compromis.

Mettre à jour une instance Docker

La très grande majorité des BTCPay Server auto-hébergés utilisent le déploiement Docker officiel (dépôt btcpayserver-docker), celui que vous obtenez en suivant la procédure d'installation de Docker sur un VPS puis le script btcpay-setup.sh. Deux méthodes de mise à jour existent, documentées par le projet.

Depuis l'interface web : menu Server Settings, onglet Maintenance, bouton Update. Le bouton ne fonctionne que si BTCPay Server a accès au SSH de l'hôte (fragment btcpay-host) ; si l'interface affiche une erreur du type « Maintenance feature requires access to SSH », passez par la ligne de commande.

Depuis le terminal SSH, en root :

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

Le script récupère le dernier commit de la branche du dépôt, régénère le fichier docker-compose, les routes nginx et les secrets, réinstalle les wrappers de commande dans /usr/local/bin puis recrée les conteneurs. Avant de remplacer les conteneurs, il archive les logs de la pile dans $BTCPAY_BASE_DIRECTORY/btcpay-update-logs/. Deux précautions recommandées par la documentation : faire une sauvegarde avant une mise à jour importante, et ne jamais modifier à la main Generated/docker-compose.generated.yml, puisque chaque mise à jour l'écrase.

Après la mise à jour, vérifiez que tous les services sont repartis et surveillez le log de l'application :

docker-compose -f "$BTCPAY_DOCKER_COMPOSE" ps
docker-compose -f "$BTCPAY_DOCKER_COMPOSE" logs -f btcpayserver

Si un conteneur reste en erreur, btcpay-restart.sh redémarre la pile complète. Puis retournez dans l'interface : le pied de page doit afficher 2.4.7.

Mettre à jour une installation manuelle (bare metal)

Certains administrateurs compilent BTCPay Server depuis les sources, avec NBXplorer, PostgreSQL et Bitcoin Core installés directement sur un serveur dédié. La documentation officielle rappelle que ce mode n'est pas recommandé en production sans une solide expertise système, et c'est exactement le profil d'instance qui prend du retard : aucune notification, aucun bouton, la mise à jour dépend d'une intervention humaine. La procédure documentée consiste à arrêter le service, récupérer le dernier tag de version, recompiler et relancer :

sudo systemctl stop btcpay
cd ~/src/btcpayserver
git fetch --tags
git checkout $(git tag --sort -version:refname | awk 'match($0, /^v[0-9]+\.[0-9]+\.[0-9]+$/)' | head -n 1)
./build.sh
sudo systemctl start btcpay
sudo journalctl -xe --unit btcpay --follow

La commande git checkout sélectionne le tag le plus récent au format vX.Y.Z, donc v2.4.7 au moment où nous écrivons. Le fichier de configuration vit dans /etc/btcpay/btcpay.config et les données dans ~/.btcpayserver/Main : ni l'un ni l'autre ne sont touchés par la recompilation. Pensez aussi à NBXplorer, dont le bulletin 2.4.2 recommandait la mise à jour vers la 2.6.10 au minimum : même logique, git fetch --tags, checkout du dernier tag, ./build.sh, redémarrage du service nbxplorer.

Instance en 2.4.1 ou antérieure : repartir sur un serveur neuf

C'est la consigne la plus forte de l'alerte, et celle que beaucoup d'administrateurs vont être tentés d'ignorer. Si votre instance tournait en 2.4.1 ou antérieure au moment de 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, et même si vous avez mis à jour depuis. La raison : impossible de savoir si l'attaquant a laissé un accès, récupéré la seed du hot wallet ou copié les secrets de la machine. Une instance mise à jour en 2.4.7 sur un serveur déjà compromis reste un serveur compromis.

Les quatre étapes publiées par l'équipe BTCPay Server :

1. Créer un nouveau portefeuille avec une nouvelle seed sur un appareil de confiance, puis y transférer (sweep) les fonds restants du hot wallet. Réutiliser l'ancienne seed laisse ces fonds à la merci de l'attaquant.
2. Mettre l'ancien serveur hors ligne et conserver les logs et l'historique des transactions : ils serviront à l'enquête et à la déclaration. Les journaux auditd, s'ils étaient activés, retracent les actions effectuées sur la machine.
3. Provisionner une VM neuve, y installer la dernière version depuis les sources officielles et y connecter le nouveau portefeuille. Ne restaurez pas l'ancien serveur en bloc sur la nouvelle machine : vous restaureriez aussi ce que l'attaquant y a laissé.
4. Révoquer et remplacer toutes les credentials exposées depuis un appareil de confiance : accès hébergeur, clés SSH, comptes BTCPay, clés API Greenfield, credentials Lightning. Ne saisissez jamais les nouveaux secrets sur l'ancienne machine.

Si des fonds ont été volés ou si vous constatez des signes d'accès non autorisé, écrivez à security@btcpayserver.org en indiquant la version que vous utilisiez (et l'historique de vos mises à jour si vous le connaissez), le moment où vous avez repéré l'incident avec votre fuseau horaire, et les identifiants de transaction et adresses concernés. Déposez aussi plainte auprès des autorités locales. Le projet insiste : n'envoyez jamais de seed, de clé privée ni de mot de passe, et retirez les secrets des logs et fichiers de configuration avant de les partager. Si votre serveur était chez un hébergeur, contactez son support pour obtenir une VM neuve et conservez l'ancienne machine hors ligne le temps de l'analyse.

Sécuriser un BTCPay Server sur VPS : reverse proxy, mises à jour, cold storage

Mettre à jour corrige la faille du jour. Les mesures ci-dessous limitent les dégâts de la prochaine, qui arrivera : la 2.4.7 a corrigé 85 problèmes de sécurité issus d'un seul audit automatisé, et l'équipe BTCPay Server reconnaît elle-même que les outils d'analyse de code rendent la découverte de failles plus rapide et moins chère qu'avant.

Ne pas exposer le backend : reverse proxy et pare-feu

Le déploiement Docker standard embarque son propre nginx (BTCPAYGEN_REVERSEPROXY="nginx") qui écoute sur les ports 80 et 443, obtient le certificat Let's Encrypt et route le trafic vers BTCPay Server. Gardez ce réglage, et n'ouvrez dans le pare-feu que les ports nécessaires : 80 et 443 pour le web, 9735 uniquement si vous faites tourner un noeud Lightning LND ou Core Lightning. Rien d'autre ne doit être joignable depuis internet, et un inventaire des ports en écoute avec ss confirme vite ce qui dépasse. Les routes nginx optionnelles lnd-rest et lnd-grpc, qui exposent l'API du noeud Lightning sur le domaine public, sont désactivées par défaut : ne les activez que si un portefeuille externe en a besoin, et rappelez-vous qu'en août les attaquants ciblaient justement les credentials LND.

Si vous placez BTCPay derrière votre propre reverse proxy nginx (par exemple pour mutualiser un VPS avec d'autres services), la documentation impose trois variables avant de relancer le setup, puis l'exclusion du compagnon HTTPS embarqué :

export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAY_HOST="btcpay.exemple.fr"
export BTCPAY_PROTOCOL="https"
export TRUST_DOWNSTREAM_PROXY="true"
. ./btcpay-setup.sh -i
btcpay-fragments exclude nginx-https

Avec TRUST_DOWNSTREAM_PROXY="true", BTCPay fait confiance aux en-têtes X-Forwarded-* reçus : le port HTTP interne du conteneur nginx (déplacé en REVERSEPROXY_HTTP_PORT=10080 quand le proxy tourne sur le même hôte) ne doit donc jamais être accessible publiquement, sinon n'importe qui peut forger ces en-têtes. Filtrez-le au pare-feu pour qu'il ne réponde qu'au proxy. Pour l'administration, un accès via un réseau privé Tailscale évite d'exposer quoi que ce soit de plus.

Mises à jour : ne plus dépendre d'un humain qui pense à cliquer

Les instances vidées avaient trois mois de retard sur un correctif critique annoncé publiquement. BTCPay Server ne se met pas à jour tout seul : la politique Check releases on GitHub (Server Settings, Policies) interroge une fois par jour les releases GitHub et affiche une notification dans l'interface, mais quelqu'un doit encore lancer la mise à jour. Trois leviers complémentaires :

• Abonnez-vous aux releases du dépôt GitHub et au compte X du projet : c'est par ces canaux que le projet a diffusé ses deux alertes de 2026.
• Planifiez btcpay-update.sh dans une tâche cron hebdomadaire si vous acceptez une mise à jour sans relecture des notes de version. Le script archive ses logs ; en contrepartie, une release qui change un comportement (la 2.4.7 supprime par exemple les anciennes routes /invoices/create) peut casser une intégration sans prévenir. Un compromis raisonnable pour une boutique à faible volume, moins pour une instance partagée entre plusieurs commerçants.
• Automatisez au moins l'OS : les mises à jour de sécurité automatiques d'Ubuntu (unattended-upgrades) couvrent le noyau, OpenSSL, Docker et tout ce qui entoure BTCPay.

Cold storage : ne gardez sur le serveur que ce que vous acceptez de perdre

La leçon principale des deux incidents de 2026 n'est pas technique. Les administrateurs qui recevaient leurs paiements sur un portefeuille matériel ou un portefeuille externe n'ont rien perdu, quelle que soit leur version. BTCPay Server propose trois façons de configurer le portefeuille d'une boutique, et une seule stocke la clé privée sur le serveur :

Pour une boutique, le réglage sain consiste à importer la clé publique (xpub) d'un portefeuille matériel avec BTCPay Vault : le serveur génère des adresses de réception, les fonds arrivent directement en cold storage, et chaque dépense se signe sur l'appareil (« Sign with a hardware wallet »). Si un hot wallet reste indispensable au quotidien (payouts automatiques, Lightning), transférez régulièrement l'excédent vers le cold storage, comme l'équipe le recommandait déjà en août. Et si plusieurs utilisateurs ont des boutiques sur votre instance, sachez que l'administrateur du serveur peut interdire la génération de portefeuilles aux non-administrateurs depuis les politiques du serveur : la 2.4.7 corrige d'ailleurs un contournement de cette politique « cold wallet only » via l'API.

Comptes, SSH et sauvegardes

• Activez la double authentification (TOTP ou clé FIDO2) sur chaque compte administrateur. La 2.4.2 a corrigé un contournement de la 2FA par authentification Basic et la 2.4.7 renforce la limite de tentatives sous connexions concurrentes : la 2FA ne vaut que sur une version à jour.
• Désactivez l'inscription publique dans Server Settings, Policies, sauf si vous hébergez volontairement d'autres commerçants ; dans ce cas, exigez la confirmation par e-mail.
• Durcissez l'accès SSH du VPS : clés uniquement, root interdit, UFW et Fail2ban. L'intégralité des secrets de BTCPay (seed du hot wallet, macaroons LND, mot de passe PostgreSQL) est sur le disque : sécuriser SSH revient à sécuriser le coffre.
• Sauvegardez avec le script officiel, chiffré, et copiez l'archive hors du serveur :

  export BTCPAY_BACKUP_PASSPHRASE="une-phrase-longue"
  cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
  ./btcpay-backup.sh

  L'archive backup.tar.gz.gpg est écrite dans /var/lib/docker/volumes/backup_datadir/_data/ et contient les volumes Docker, les secrets générés et le dump PostgreSQL, sans la blockchain. Expédiez-la vers un stockage distant avec rsync ou une sauvegarde chiffrée hors site. Attention si vous opérez un noeud Lightning : la documentation prévient que restaurer un ancien état de canal peut faire perdre tous les fonds du canal, gardez une copie séparée de channel.backup et de la seed LND.

Quel VPS pour redéployer un BTCPay Server propre

Puisque le projet recommande une VM neuve pour toute instance qui tournait en 2.4.1 ou moins, autant la dimensionner correctement. La documentation BTCPay donne, pour un déploiement Bitcoin seul avec un noeud élagué (opt-save-storage-xs, 25 Go de blocs conservés), un minimum de 4 Go de RAM, 2 vCPU et 50 Go de SSD, en précisant qu'un plan plus large est préférable pour la marge. Les paliers d'élagage disponibles via BTCPAYGEN_ADDITIONAL_FRAGMENTS :

Ajouter Litecoin (BTCPAYGEN_CRYPTO2) signifie un second noeud complet, donc un second volume de blocs et environ 8 Go de plus sur le disque système d'après la formule de la documentation. Chez ElypseCloud, le VPS Linux Classic (4 vCPU, 8 Go de RAM, 70 Go SSD) couvre un BTCPay Bitcoin seul avec de la marge ; pour Bitcoin plus Litecoin ou un noeud Lightning actif, le palier Pro (6 vCPU, 16 Go de RAM, 100 Go SSD) évite de revenir sur le dimensionnement six mois plus tard. Tous nos VPS Linux sont des machines virtuelles KVM à ressources garanties, le terrain attendu par Docker et par un noeud Bitcoin. Après provisionnement, suivez le parcours de premiers réglages avant même d'installer BTCPay, puis obtenez le certificat via le nginx embarqué plutôt qu'un certbot séparé, sauf reverse proxy externe.

Dernier rappel, parce que c'est tout l'objet de cette alerte : installez directement la 2.4.7, créez le portefeuille en watch-only ou depuis un hardware wallet, et notez quelque part la date de la prochaine vérification de version. Les instances vidées le 1er novembre avaient simplement oublié cette dernière étape.