ActualitésCryptoL'attaquant s'est connecté en tant qu'administrateur sur des serveurs BTCPay obsolètes avant les vides de hot wallets, selon le fondateur

L'attaquant s'est connecté en tant qu'administrateur sur des serveurs BTCPay obsolètes avant les vides de hot wallets, selon le fondateur

Auteur: Cryptopolitan·

Points clés

  • •Les vides de hot wallets de dimanche ont ciblé des instances de BTCPay Server exécutant la version 2.4.1, publiée le 23 juillet, ou des versions antérieures, selon la mise à jour d'enquête du projet.
  • •BTCPay a émis une alerte exhortant tous les opérateurs à arrêter leurs instances et n'a signalé aucun vide crédible de hot wallet chez les utilisateurs de la version 2.4.7, publiée le 29 octobre.
  • •Dans les intrusions signalées, les attaquants se sont connectés en tant qu'administrateurs, et BTCPay n'a pas encore déterminé comment cet accès avait été obtenu.
  • •La version 2.4.2, publiée le 7 août, corrigeait une faille activement exploitée permettant à des attaquants non authentifiés de voler les identifiants macaroon de LND et de prendre le contrôle de nœuds Lightning, mais BTCPay n'a pas confirmé si ce bug avait été utilisé dimanche, notant que le bug d'août ne nécessitait aucune authentification alors que les attaques de dimanche impliquaient des connexions administrateur.
  • •Dorier a déclaré que les opérateurs ayant effectué au moins une mise à jour depuis la sortie de la 2.4.2 n'ont aucune raison de paniquer, tout en avertissant les utilisateurs de ne pas détenir trop de fonds dans un hot wallet.
L'attaquant s'est connecté en tant qu'administrateur sur des serveurs BTCPay obsolètes avant les vides de hot wallets, selon le fondateur

Les vides de hot wallets signalés dimanche semblent avoir ciblé des instances de BTCPay Server exécutant des versions antérieures à la 2.4.2, selon Nicolas Dorier, fondateur de BTCPay Server. Dans ces cas, l'attaquant s'est connecté en tant qu'administrateur, et l'équipe a indiqué qu'elle cherchait encore à déterminer comment cet accès avait été obtenu.

L'enquête pointe vers la version 2.4.1 ou antérieure

BTCPay a émis une alerte à 17 h 25 HE dimanche, publiée sur X, exhortant toute personne exploitant une instance à l'arrêter avec ./btcpay-down.sh jusqu'à la fin de l'enquête. Dorier a publié un suivi environ deux heures plus tard, précisant que les serveurs publics de BTCPay, en version 2.4.7, n'avaient pas été attaqués. Il a ensuite déclaré que l'équipe disposait de traces indiquant que « des vulnérabilités antérieures à la 2.4.2 avaient été utilisées ».

Une mise à jour publiée par BTCPay à 23 h 07 HE (ici et ici) a précisé la cible : les enquêteurs ont identifié un vecteur d'attaque visant les instances exécutant la version 2.4.1, publiée le 23 juillet, ou des versions antérieures.

Le projet n'a signalé « aucun signalement crédible de vide de hot wallet » chez les utilisateurs de la 2.4.7, publiée le 29 octobre. Il a conseillé aux opérateurs de maintenir leur logiciel à jour et a demandé aux victimes d'envoyer les détails et journaux à son équipe de sécurité.

Certains hébergeurs ont peut-être arrêté automatiquement des instances pour empêcher l'exploitation des versions plus anciennes. BTCPay a remercié LunaNode et d'autres pour leur action rapide. Dorier a déclaré que les opérateurs ayant effectué au moins une mise à jour depuis la sortie de la 2.4.2 n'ont « aucune raison de paniquer », tout en avertissant les utilisateurs de ne pas détenir trop de fonds dans un hot wallet et en promettant un article de blog avec plus de détails.

Les vides de dimanche ont atteint des fonds que l'avis d'août jugeait sûrs

BTCPay étant auto-hébergé, le projet ne peut ni modifier ni arrêter le serveur d'un marchand. Son mode hot wallet signe les paiements avec une seed stockée sur ce serveur, ce qui signifie que quiconque contrôle le serveur peut déplacer les coins, selon la documentation de BTCPay. En pratique, une version de sécurité telle que la 2.4.2 ne protège un serveur donné qu'une fois installée par son opérateur.

La version 2.4.2 remonte à août. BTCPay a publié la 2.4.2 le 7 août pour corriger une vulnérabilité critique déjà activement exploitée, comme l'avait rapporté Cryptopolitan à l'époque. Toutes les versions antérieures, y compris les release candidates de la 2.4.2, permettaient à un attaquant non authentifié de voler les identifiants macaroon de LND, lui permettant de prendre le contrôle d'un nœud Lightning et de déplacer ses fonds. Le projet a détaillé le correctif dans son avis de sécurité. Foundation et Citadel21 ont signalé des attaques contre leurs nœuds Lightning, et Craig Raw, développeur de Sparrow Wallet, a dit avoir également été touché.

Avec la version 2.4.2, les macaroons de LND ont été régénérés automatiquement. Les opérateurs qui exposaient LND via leur propre proxy, un service Tor ou un port redirigé ont toutefois dû modifier ces identifiants manuellement. La version 2.4.2 a également corrigé un contournement distinct de la double authentification TOTP via l'authentification Basic de l'API Greenfield, signalé le 4 août. BTCPay a précisé que ce bug n'était pas lié au piratage des macaroons et que ses propres wallets on-chain, y compris les hot wallets, n'étaient pas affectés par cette faille.

Ni BTCPay ni Dorier n'ont précisé si l'attaquant de dimanche avait exploité le bug des macaroons d'août ou une autre vulnérabilité antérieure à la 2.4.2. Le bug des macaroons d'août était exploitable sans aucune authentification ; les intrusions de dimanche, en revanche, impliquaient des connexions administrateur. En août, les soutiens du projet avaient mis en place une prime de récupération de 10 % des fonds restitués, jusqu'à 3 BTC, comme l'avait rapporté Cryptopolitan. Par ailleurs, River a rapporté que l'utilisation moyenne de Bitcoin par les marchands avait augmenté de 74 % en 2025, le volume Lightning dépassant 1 milliard de dollars par mois — le type d'activité de paiement marchand que des logiciels auto-hébergés comme BTCPay sont conçus pour traiter.