Vols de hot wallets BTCPay Server, corrigés dans 2.4.2

TL;DR

• Des attaquants ont volé du bitcoin et du litecoin dans les hot wallets de serveurs tournant sous BTCPay Server 2.4.1 ou une version antérieure, via la vulnérabilité corrigée dans 2.4.2 le 7 août 2026. L'éditeur a divulgué les vols le 2 novembre 2026.
• Toutes les versions antérieures à 2.4.2, y compris les release candidates de 2.4.2, sont concernées. Les attaques d'août ont pris le contrôle de nœuds LND du Lightning Network ; les vols de novembre ont vidé les hot wallets on-chain des serveurs.
• L'éditeur qualifie la faille de critique et rapporte des vols de fonds en août et le 1er novembre 2026. Aucun CVE n'est attribué, et la faille ne figure pas au catalogue KEV de la CISA au 3 novembre 2026.
• Si vous utilisez 2.4.1 ou une version antérieure, migrez vers un serveur neuf avec un nouveau portefeuille après avoir balayé vos fonds. Une simple mise à jour ne peut pas retirer un accès déjà obtenu par un attaquant. Voir « Comment corriger ? ».

Suis-je concerné ?

Vous êtes exposé lorsque toutes ces conditions sont réunies :

• Votre déploiement utilise BTCPay Server 2.4.1, publiée le 23 juillet 2026, ou une version antérieure. L'avis de l'éditeur indique que la faille est présente dans toutes les versions antérieures à 2.4.2, y compris les release candidates de 2.4.2.
• L'instance était accessible depuis Internet pendant qu'elle tournait sur une version concernée. L'éditeur précise n'avoir pas établi quand les attaquants ont commencé à exploiter la faille.
• Vous n'avez pas reconstruit le serveur depuis. Les recommandations de reprise de l'éditeur s'appliquent même si vous avez mis à jour une version concernée après son avertissement du 1er novembre sans constater de vol.

Les instances hébergées sont aussi concernées : le 1er novembre, l'éditeur a demandé aux hébergeurs, dont LunaNode, de mettre hors ligne les instances de BTCPay Server par précaution. Contactez votre fournisseur pour une migration vers une machine virtuelle neuve.

Les fonds dont les clés de dépense sont conservées hors du serveur, y compris les portefeuilles matériels, n'ont pas été touchés par ces vols. Accepter les paiements vers de tels portefeuilles reste la pratique recommandée par l'éditeur.

Les versions concernées passent à côté de tous les correctifs de sécurité qui ont suivi : les versions 2.4.3 à 2.4.7 ont livré des correctifs de sécurité et de renforcement jusqu'au 29 octobre 2026. À elle seule, la version 2.4.7 corrige 85 vulnérabilités signalées par l'OSS Scanner d'Anthropic.

Malgré 7 888 étoiles GitHub et 4 131 130 téléchargements de l'image Docker officielle, aucun CVE ni avis de sécurité GitHub n'existe pour cette faille, donc les scanners de versions ne peuvent pas signaler la plage concernée.

Vérifiez ce que vous utilisez :

# Vendor's check: log in and read the version shown at the bottom of the page.

# Docker deployments: list the running container and its image tag
docker ps --format 'table {{.Names}}\t{{.Image}}' | grep -i btcpay
# If the tag reads "latest" or gives no version, the page footer is authoritative.

Comment corriger ?

1. Si vous utilisez 2.4.1 ou une version antérieure, suivez les étapes de reprise de l'éditeur plutôt qu'une mise à jour sur place :
2. Créez un nouveau portefeuille et balayez-y les fonds restants du hot wallet. Utilisez un appareil de confiance et une nouvelle graine ; réutiliser l'ancienne graine sur un nouveau serveur laisse ces fonds en danger.
3. Mettez l'ancien serveur hors ligne, et conservez les journaux et relevés de transactions utiles à l'enquête avant de le remplacer.
4. Préparez une machine virtuelle neuve, installez la dernière version prise en charge depuis des sources de confiance et connectez le nouveau portefeuille. Ne restaurez pas tout l'ancien serveur sur la nouvelle machine.
5. Depuis un appareil de confiance, révoquez et remplacez chaque identifiant auquel l'ancien serveur pouvait accéder. Ne saisissez pas de nouveaux identifiants sur l'ancienne machine. L'éditeur cite :
   • les identifiants d'hébergement et SSH
   • les identifiants applicatifs et d'API
   • les identifiants Lightning
6. Si votre serveur tournait déjà sous 2.4.2 ou une version ultérieure au 1er novembre, l'éditeur n'a constaté aucun impact de ces attaques sur ces serveurs. Mettez quand même à jour vers la version actuelle, car 2.4.7 corrige 85 vulnérabilités supplémentaires.
7. Pour une installation standard, utilisez le chemin de mise à jour de l'éditeur (Server Settings, puis Maintenance, puis Update) et confirmez que le pied de page affiche la nouvelle version.
8. Les intégrateurs doivent aussi mettre à jour NBXplorer vers 2.6.10, comme le recommandent les notes de version de 2.4.2.

Aucune solution de contournement par configuration n'existe pour la faille elle-même. En août, le conseil provisoire de l'éditeur pour les utilisateurs de LND ne pouvant pas mettre à jour était de mettre le serveur hors ligne. Un déploiement LND concerné ne doit jamais rester accessible depuis Internet.

Quelle est la cause racine ?

BTCPay Server a fermé deux expositions le même jour : des méthodes utilitaires publiques de contrôleurs étaient routables comme points d'entrée HTTP, et le déploiement Docker de référence exposait les API de LND via le domaine public. L'éditeur indique ne pas encore publier les détails techniques, pour laisser aux opérateurs le temps de mettre à jour.

Le correctif côté serveur est le commit 6689cad419, « Disabled unwanted routes », poussé le 7 août 2026 par le mainteneur Nicolas Dorier sans pull request ni entrée de journal des modifications. Il ajoute l'attribut [NonAction] à cinq méthodes utilitaires publiques de contrôleurs, dont celle-ci :

// BTCPayServer/Controllers/UILNURLController.cs, before 2.4.2
public async Task<IActionResult> GetLNURLRequest(
    string cryptoCode,
    Data.StoreData store,
    ...)

// after 2.4.2
[NonAction]
public async Task<IActionResult> GetLNURLRequest(
    string cryptoCode,
    Data.StoreData store,
    ...)

ASP.NET Core associe chaque méthode publique d'une classe de contrôleur à un point d'entrée HTTP routable, sauf si elle porte [NonAction]. Les cinq méthodes utilitaires se trouvent sur les contrôleurs LNURL, LNURL-authentication, stores, email-rule et subscription. Chacune est un bloc interne jamais prévu pour recevoir une requête.

Le même jour, le commit « Do not expose LND anymore » du dépôt docker a retiré les deux emplacements nginx qui reliaient le domaine public directement au nœud Lightning :

# Production/nginx.tmpl in btcpayserver-docker, removed on 2026-08-07
location ~* ^/(lnrpc|routerrpc|verrpc|walletrpc)\. {
    grpc_read_timeout 6000s;
    grpc_send_timeout 6000s;
    grpc_pass grpcs://lnd_bitcoin:10009;
}
location /lnd-rest/btc/ {
    rewrite ^/lnd-rest/btc/(.*) /$1 break;
    proxy_pass http://lnd_bitcoin:8080/;
}

Un troisième commit le même jour nomme la classe de la faille. En annulant une suppression voisine, le mainteneur Andrew Camilleri a écrit que CLN, une autre implémentation du Lightning Network, « is not affected by the LNURL issue ». BTCPay atteint CLN via un socket Unix avec des runes, donc « there is no macaroon for that code path to read », selon ses mots. Son message indique que le chemin de code LNURL lit le macaroon LND.

L'avis d'août décrit le résultat : un attaquant distant non authentifié pouvait obtenir les fichiers d'identifiants .macaroon de LND.

Comment la faille est-elle exploitée ?

Les deux publications de l'éditeur décrivent le chemin d'attaque ; aucune preuve de concept publique n'existe, et l'éditeur n'a pas publié les requêtes envoyées par les attaquants :

1. L'attaquant atteint un serveur concerné via Internet. L'avis d'août indique que l'obtention des fichiers d'identifiants .macaroon ne nécessitait aucune authentification.
2. Lors des attaques d'août, l'attaquant a obtenu les fichiers .macaroon, qui portent un accès authentifié à un nœud LND. L'éditeur a examiné des attaques ne ciblant que des fichiers avec l'extension .macaroon, et indique que ces identifiants permettaient de prendre le contrôle du nœud et de déplacer des fonds.
3. Lors des attaques de novembre, l'attaquant a utilisé « a different method to exploit the vulnerability fixed in 2.4.2 », selon les mots de l'éditeur. Les vols ont pris du bitcoin et du litecoin dans les hot wallets on-chain des serveurs, et l'éditeur n'a pas décrit cette méthode.
4. Aucun accès supplémentaire n'était nécessaire pour dépenser les fonds, car un hot wallet conserve sur le serveur même les clés nécessaires à leur dépense. Les portefeuilles dont les clés de dépense sont hors du serveur n'ont pas été touchés.

Comment l'attaque se déroule-t-elle ?

Une requête non authentifiée atteint des routes que l'éditeur n'avait jamais prévu d'exposer, et l'attaquant prend les macaroons LND ou, en novembre, les fonds des hot wallets on-chain.

Que peut faire un attaquant ?

Les attaques d'août ont pris le contrôle d'un nœud LND et déplacé ses fonds, y compris le portefeuille on-chain appartenant au nœud lui-même. Les attaques de novembre ont volé du bitcoin et du litecoin dans les hot wallets on-chain des serveurs, que l'éditeur avait jugés non concernés en examinant les attaques d'août.

Une fois entré, l'attaquant est considéré comme propriétaire de la machine. L'éditeur dit à quiconque a subi un vol ou constate des signes d'accès non autorisé de considérer l'ensemble du serveur et tous ses secrets comme compromis. Les mêmes étapes de reprise s'appliquent.

Deux conditions bornent l'impact. Le serveur doit tourner sous 2.4.1 ou une version antérieure. Seuls les fonds que le serveur pouvait dépenser lui-même étaient en risque, donc les portefeuilles matériels et les autres clés conservées ailleurs sont restés hors d'atteinte.

Pourquoi le correctif fonctionne-t-il ?

La version 2.4.2 ferme les deux expositions. Les attributs [NonAction] retirent les cinq méthodes utilitaires du routage, donc elles ne peuvent plus recevoir de requêtes. Le changement nginx retire les interfaces gRPC et REST de LND du domaine public.

Le coût documenté est que les portefeuilles externes comme Zeus perdent l'accès à LND via le domaine BTCPay. L'éditeur prévoit de rétablir ce chemin quand ce sera sûr.

Deux changements le même jour invalident ce qui avait déjà été volé. Le dépôt docker passe LND en 0.21.1, et le réglage LND_MACAROON_ROTATION_ID ajouté le 7 août régénère les macaroons. Les fichiers macaroon pris avant la mise à jour cessent de fonctionner.

Le correctif est complet pour les deux expositions que les commits ferment, mais il ne peut pas retirer un accès déjà obtenu par un attaquant. C'est pourquoi l'éditeur demande aux opérateurs des versions concernées de migrer vers un serveur neuf plutôt que de mettre à jour sur place.

La version 2.4.2 corrige aussi un contournement de l'authentification à deux facteurs TOTP via l'authentification Basic Greenfield. Elle désactive l'authentification Basic par défaut cinq minutes après la création du compte.

Comment savoir si j'ai été compromis ?

Vérifiez d'abord la version : connectez-vous et lisez le pied de page. Vérifiez ensuite la blockchain et votre nœud Lightning :

• L'éditeur a publié deux adresses de destination identifiées dans les signalements d'incident. Cherchez des transferts sortants vers l'adresse bitcoin bc1p0f7wmcnesrapznymf9ljdn04pudgmh96sqtrm9vmgqxdh666fh8qvn63r7 ou l'adresse litecoin ltc1qp49tmfdueyaqrmgrx0uyx4uegyygt8yt02whee.
• Traitez une correspondance comme un indice parmi d'autres. L'éditeur avertit qu'une partie de l'activité sur ces adresses semble antérieure aux vols décrits dans ses signalements, donc leurs soldes et historiques ne sont pas un total de pertes confirmé.
• Si vous utilisez ou avez utilisé LND, appliquez les quatre vérifications de l'avis d'août de l'éditeur :
• des paiements que vous n'avez pas effectués
• des fermetures de canaux inattendues ou des pairs inconnus
• les soldes on-chain et de canaux comparés à vos propres relevés
• toute activité que vous ne reconnaissez pas
• Un solde de portefeuille inchangé n'exclut pas une attaque antérieure. Si le serveur tournait sous 2.4.1 ou une version antérieure et était accessible, considérez la machine et tous ses secrets comme compromis. Conservez les journaux, puis suivez les étapes de « Comment corriger ? ».

Chronologie

• 2026-07-23 : BTCPay Server 2.4.1 est publiée, dernière version portant la faille.
• 2026-08-06 au 2026-08-07 : les mainteneurs livrent le correctif composite sur les dépôts serveur et docker : « Disabled unwanted routes », « Do not expose LND anymore » et la rotation des macaroons.
• 2026-08-07 : BTCPay Server 2.4.2 est publiée. L'avis indique que des attaquants avaient déjà exploité la faille et que des fonds avaient été volés.
• 2026-08-24 : 2.4.3 est publiée comme version de sécurité pour les serveurs partagés entre plusieurs utilisateurs.
• 2026-09-07 : 2.4.4 livre des renforcements du paiement et des boutiques.
• 2026-10-06 : 2.4.5 bloque par défaut les destinations en réseau privé pour les requêtes sortantes.
• 2026-10-26 : 2.4.6 renforce les permissions d'API, les entrées non fiables, les liens générés et les actions du navigateur.
• 2026-10-29 : 2.4.7 corrige 85 vulnérabilités signalées via l'OSS Scanner d'Anthropic.
• 2026-11-01 : un vidage de portefeuille décrit dans les signalements d'incident se produit à 13 h 46 UTC. Le premier signalement de vol arrive par courriel à 20 h 56 UTC, et l'éditeur avertit la communauté à 22 h 25 UTC.
• 2026-11-02 : l'éditeur nomme 2.4.1 et les versions antérieures comme versions concernées et publie les recommandations de reprise.

FAQ

Je n'utilise pas LND. Suis-je quand même en danger ?

Les attaques d'août examinées par l'éditeur ne ciblaient que les fichiers macaroon LND, et les utilisateurs d'autres implémentations du Lightning Network n'étaient pas exposés à ce risque d'identifiants. Les vols de novembre ont pris du bitcoin et du litecoin dans les hot wallets on-chain de serveurs sous 2.4.1 ou antérieures. Les recommandations de reprise s'appliquent désormais à tout déploiement concerné, pas seulement aux utilisateurs de LND.

J'ai mis à jour vers 2.4.2 ou une version ultérieure après l'avertissement du 1er novembre. Suis-je en sécurité ?

L'éditeur n'a constaté aucun impact sur les serveurs tournant déjà sous 2.4.2 ou une version ultérieure au moment de l'avertissement. Si vous avez mis à jour depuis 2.4.1 ou antérieure après cet avertissement, l'éditeur vous demande quand même de migrer vers un serveur neuf avec un nouveau portefeuille. Une mise à jour ne peut pas retirer un accès déjà obtenu par un attaquant.

Existe-t-il un CVE à scanner ?

Non. Au 3 novembre 2026, aucun CVE n'a été attribué et le dépôt GitHub ne contient aucun avis de sécurité, donc les scanners de dépendances ne peuvent pas signaler la plage concernée. La version affichée en bas de page est la seule vérification de version, et les étapes de « Comment corriger ? » sont la remédiation.

Mes fonds sur portefeuille matériel sont-ils en sécurité ?

Oui. Les fonds des portefeuilles dont les clés de dépense sont conservées hors du serveur, y compris les portefeuilles matériels, n'ont pas été touchés par ces vols. L'éditeur recommande quand même de reconstruire un ancien serveur même si vous gardez vos clés ailleurs, car l'attaquant peut détenir d'autres accès à la machine.

Qu'ont changé les versions postérieures à 2.4.2 ?

Ce sont des versions de sécurité et de renforcement. La version 2.4.5 bloque par défaut les destinations en réseau privé pour les connexions Lightning, les requêtes LNURL, les URL de notification de facture et les webhooks. La version 2.4.7 corrige 85 vulnérabilités signalées via l'OSS Scanner d'Anthropic : une critique, 13 élevées, 52 moyennes et 19 faibles.

Trouvez les serveurs de paiement exposés avec Ostorlab

La découverte de la surface d'attaque d'Ostorlab inventorie vos hôtes exposés sur Internet et les services qu'ils proposent. Utilisez-la pour lister les serveurs qui exécutent un processeur de paiement auto-hébergé, et vérifiez d'abord ces versions.

Références

• Blog BTCPay Server, « Security Incident Affecting BTCPay Server 2.4.1 and Earlier », 2 novembre 2026, les signalements de vol, les étapes de reprise, la chronologie et les adresses de destination : https://blog.btcpayserver.org/btcpay-server-security-incident-2-4-1-and-earlier/ (consulté le 3 novembre 2026)
• Blog BTCPay Server, « Security Advisory: Update BTCPay Server to 2.4.2 Immediately », 7 août 2026, le vol non authentifié de .macaroon, le périmètre LND, les crédits et les conseils provisoires : https://blog.btcpayserver.org/security-advisory-btcpay-server-2-4-2/ (consulté le 3 novembre 2026)
• Commit btcpayserver 6689cad41979c73f769fd42e38268fed1fa800fa, « Disabled unwanted routes », Nicolas Dorier, 7 août 2026, les cinq ajouts [NonAction] : https://github.com/btcpayserver/btcpayserver/commit/6689cad41979c73f769fd42e38268fed1fa800fa (consulté le 3 novembre 2026)
• Commit btcpayserver-docker 21ea2e122ae5bc453ad1c0a4d6d6b6dd094dcca2, « Do not expose LND anymore », Nicolas Dorier, 7 août 2026, les emplacements nginx retirés : https://github.com/btcpayserver/btcpayserver-docker/commit/21ea2e122ae5bc453ad1c0a4d6d6b6dd094dcca2 (consulté le 3 novembre 2026)
• Commit btcpayserver-docker c48919f9ae51c714078076e7912dd153ba0bb01f, « Revert 'Do not expose CLN REST anymore' », Andrew Camilleri, 7 août 2026, la description de la classe « LNURL issue » et le chemin de code du macaroon : https://github.com/btcpayserver/btcpayserver-docker/commit/c48919f9ae51c714078076e7912dd153ba0bb01f (consulté le 3 novembre 2026)
• Commit btcpayserver-docker 4caadeb0c3a31f88ca1a4ee46fd63d8b9db093c0, « Triggering macaroon regeneration », rockstardev, 7 août 2026, le réglage LND_MACAROON_ROTATION_ID : https://github.com/btcpayserver/btcpayserver-docker/commit/4caadeb0c3a31f88ca1a4ee46fd63d8b9db093c0 (consulté le 3 novembre 2026)
• Notes de version BTCPay Server v2.4.2, 7 août 2026, la déclaration d'exploitation, les crédits, le correctif du contournement TOTP et la recommandation NBXplorer 2.6.10 : https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.2 (consulté le 3 novembre 2026)
• Notes de version BTCPay Server v2.4.7, 29 octobre 2026, les 85 vulnérabilités par sévérité issues de l'OSS Scanner d'Anthropic : https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.7 (consulté le 3 novembre 2026)
• Publication BTCPay Server v2.4.1, 23 juillet 2026 : https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.1 (consulté le 3 novembre 2026)
• Notes de version BTCPay Server v2.4.5, 6 octobre 2026, le blocage par défaut des destinations en réseau privé : https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.5 (consulté le 3 novembre 2026)
• Dépôt btcpayserver/btcpayserver, 7 888 étoiles, et son image Docker Hub, 4 131 130 téléchargements, les chiffres d'ampleur : https://github.com/btcpayserver/btcpayserver et https://hub.docker.com/r/btcpayserver/btcpayserver (consulté le 3 novembre 2026)
• The Hacker News, « Hackers Exploit BTCPay Server Flaw to Steal Bitcoin and Litecoin From Hot Wallets », 3 novembre 2026, la note d'accès Zeus et les mises hors ligne d'hébergeurs : https://thehackernews.com/2026/11/hackers-exploit-btcpay-server-flaw-to.html (consulté le 3 novembre 2026)
• Flux JSON du catalogue KEV de la CISA, vérifié pour des entrées BTCPay Server le 3 novembre 2026 (aucune) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (consulté le 3 novembre 2026)