Le portefeuille chaud de BTCPay Server a été compromis. L’équipe officielle a publié une alerte sur X, recommandant à tous les opérateurs d’instances d’arrêter immédiatement leurs serveurs et de ne les remettre en ligne qu’une fois l’enquête terminée.
Le message officiel indique que « des signalements font état de portefeuilles chauds de plusieurs instances vidés par des attaquants non autorisés ». Mais l’alerte ne précise pas quelles versions sont concernées, ne confirme pas le montant des pertes et ne publie aucun correctif. La consigne d’arrêt ne fait aucune distinction entre les versions : elle s’applique à toutes. Cette approche consistant à « tout arrêter d’abord, enquêter ensuite » est en soi révélatrice : tant que le mode opératoire de l’attaque n’est pas élucidé, il est impossible de déterminer quelles configurations sont sûres.
Si le portefeuille chaud de BTCPay est au cœur de cet incident, c’est directement lié à sa conception. Cette fonctionnalité stocke la seed sur le serveur et l’utilise pour signer les transactions localement, sans nécessiter de dispositif matériel externe. Elle offre davantage d’automatisation et de commodité, mais en contrepartie, si le serveur est compromis, la seed est exposée et les fonds peuvent être transférés directement. BTCPay est un logiciel auto-hébergé : la décision de désactiver un serveur, et le moment de le faire, revient en dernier ressort à chaque exploitant, l’équipe officielle ne pouvant que le recommander. Cela signifie également que l’ampleur de l’impact de cet incident de sécurité dépend en grande partie de la rapidité avec laquelle les exploitants réagissent à l’alerte.
Une chronologie mérite d’être examinée à part. Le 29 octobre, BTCPay Server a publié une mise à jour d’urgence, la version 2.4.7, qui corrigeait une vulnérabilité critique et plusieurs vulnérabilités de gravité moyenne. Puis, entre le 1er et le 2 novembre, les premiers signalements de vols dans des portefeuilles chauds ont commencé à apparaître. Les responsables n’ont pas indiqué si cet incident était lié aux vulnérabilités corrigées le 29 octobre, ni si la désactivation concernait les instances qui n’avaient pas été mises à niveau vers la version 2.4.7. Un autre élément de contexte pouvant prêter à confusion est la fuite de justificatifs LND survenue en août. À l’époque, les attaquants pouvaient obtenir des fichiers macaroon et prendre le contrôle de nœuds Lightning, mais BTCPay avait clairement précisé que cette vulnérabilité n’affectait pas les portefeuilles on-chain, y compris les portefeuilles chauds. Par conséquent, invoquer l’incident d’août pour expliquer le vol des portefeuilles chauds cette fois-ci n’est pas fondé, du moins au vu des informations publiques.
Pour l’heure, une seule chose peut être confirmée : par nature, la fonction de portefeuille chaud n’offre aucune isolation lorsque le serveur est compromis. La seed se trouve sur le serveur, la signature est effectuée sur le serveur et la sécurité des fonds dépend entièrement du périmètre de sécurité du serveur lui-même. Pour les exploitants d’instances BTCPay, tant que les responsables n’auront pas précisé les versions concernées et les mesures correctives, désactiver l’instance est la seule option permettant de maîtriser activement les risques dans les circonstances actuelles. Quant à la méthode utilisée par les attaquants, à l’ampleur des pertes et à un éventuel lien avec la mise à jour de version effectuée quelques jours plus tôt, aucune réponse n’a été rendue publique à ce jour. Il ne reste qu’à attendre les conclusions de l’enquête officielle.
#BTCPayServer呼吁运营者关闭实例 #BTC $BTC
Avertissement : le contenu ci-dessus s’appuie sur l’alerte officielle de BTCPay Server et sur des informations publiques. Il vise uniquement à présenter les faits et à examiner les mécanismes de sécurité ; il ne constitue ni une consigne opérationnelle ni un conseil en investissement. Les exploitants d’instances sont invités à suivre les dernières recommandations officielles.