Sécuriser BTCPay Server : pourquoi la mise à jour 2.4.4 seule ne protège pas votre nœud Lightning

Disons-le d’emblée, car c’est la question qui vous amène ici : la mise à jour vers BTCPay Server 2.4.4 ferme la route publique par défaut vers votre nœud Lightning. Elle ne supprime pas une route que vous avez construite vous-même. Quiconque a un jour exposé l’interface LND de son serveur via son propre reverse proxy a donc deux choses à faire : mettre à jour, et retirer de nouveau cet accès. Le projet derrière BTCPay Server écrit précisément cela dans son annonce du 8 septembre 2026.

Le motif n’est pas un nouveau vol. Le projet observe des programmes automatisés qui sondent les serveurs sur lesquels cet accès a été rouvert à la main. Aucune prise de contrôle réussie par cette voie n’a été signalée à ce jour, et le projet n’établit aucun lien avec les auteurs de l’incident d’août. C’est la bonne nouvelle de l’affaire : il existe une fenêtre pendant laquelle le problème peut se résoudre sans dommage.

Pour vous, détenteur ou commerçant, l’enjeu dépasse le détail technique. Un serveur de paiement auto-hébergé est le point où convergent les paiements en bitcoin entrants, les clés de votre nœud Lightning et votre solde d’exploitation. Qui y perd l’accès perd de l’argent réel, pas de la configuration. D’où une seconde question sur le même bureau : quel solde doit vraiment rester en permanence sur un nœud relié au réseau, et qu’est-ce qui relève de la conservation hors ligne ? Si vous n’avez pas encore tracé cette limite, notre comparatif des portefeuilles matériels est un meilleur point de départ que n’importe quelle règle de proxy supplémentaire.

Ce qui se passe actuellement : des bots appellent un point d’accès LND non protégé

Le projet décrit le schéma ouvertement. Des programmes automatisés appellent de façon répétée un chemin précis de l’interface de programmation de LND : le point d’accès de changement du mot de passe du portefeuille, à l’adresse /lnd-rest/btc/v1/changepassword. Sont concernés explicitement les serveurs sur lesquels cet accès a été réactivé manuellement après que BTCPay Server l’eut désactivé par défaut en août.

Le point délicat : ce point d’accès n’exige aucune authentification tant que le portefeuille LND est encore verrouillé. Ce n’est pas un défaut au sens strict, mais la conception même de l’interface. Un portefeuille verrouillé ne peut encore authentifier personne ; la voie du déverrouillage et du changement de mot de passe doit donc rester accessible sans justificatif. Tant que cette voie n’est joignable qu’à l’intérieur du serveur, elle est sans danger. Seule sa publication sur le réseau ouvert en fait une porte d’entrée.

Macaroon, LND et reverse proxy : les trois notions sans lesquelles le reste ne tient pas

LND est l’une des implémentations répandues du réseau Lightning, la couche de paiement qui règle les virements en bitcoin en quelques secondes et pour des fractions de centime. Si votre BTCPay Server accepte les paiements Lightning, c’est presque toujours LND qui se trouve dessous.

Un macaroon est le justificatif avec lequel LND autorise les commandes. On peut se le représenter comme un fichier de clé aux droits gradués. Le macaroon d’administration est le passe-partout : celui qui le détient dispose du portefeuille et des canaux de paiement du nœud.

Un reverse proxy est le service serveur qui reçoit les requêtes venues d’internet et les transmet au bon service interne. BTCPay Server en embarque un. Beaucoup d’opérateurs en ont installé un second à côté ou devant, par exemple pour laisser un portefeuille mobile dialoguer avec leur nœud depuis l’extérieur. C’est exactement de cette redirection construite à la main qu’il est question ici.

Pourquoi la fenêtre après un redémarrage de LND existe

Le déroulé n’a rien de spectaculaire, et c’est ce qui le rend efficace. Après chaque redémarrage de LND, le portefeuille est d’abord verrouillé. BTCPay Server dispose d’un déverrouillage interne qui fournit le mot de passe automatiquement. Entre le démarrage du service et le moment où ce déverrouillage agit, il s’écoule un court laps de temps.

Si l’interface est joignable depuis le réseau ouvert pendant ce laps, un attaquant peut être plus rapide. Le projet en décrit la conséquence sobrement : qui soumet à cet instant le mot de passe connu peut en définir un nouveau et se faire délivrer par LND un macaroon d’administration permettant de piloter le nœud. À partir de là, le passe-partout appartient à quelqu’un d’autre.

Un détail du passé a aggravé les choses : les anciennes installations BTCPay créaient leurs portefeuilles LND avec un mot de passe par défaut commun. Il n’y avait donc rien à deviner. Qui connaissait ce réglage n’avait plus qu’à frapper au bon moment.

Le vol d’août et le sondage de septembre sont deux affaires distinctes

La distinction compte, car la couverture de langue allemande s’est arrêtée en août et les deux événements se confondent facilement.

L’affaire la plus ancienne, le 7 août 2026. Le projet a publié un avis de sécurité relatif à la version 2.4.2. Toutes les moutures antérieures comportaient une faille permettant à un attaquant distant non authentifié de récupérer les fichiers macaroon de LND. Le projet confirme expressément que la faille a été exploitée, que des utilisateurs ont été touchés et que des fonds sont partis. Les portefeuilles on-chain propres à BTCPay Server n’étaient pas concernés, les chauds non plus ; les avoirs du portefeuille on-chain de LND relèvent en revanche du nœud touché. Le projet et ses soutiens ont ensuite promis une récompense de 10 % des bitcoins récupérés, plafonnée à trois BTC, soit environ 190 000 dollars à l’époque.

L’affaire nouvelle, le 8 septembre 2026. Ici, aucun dommage n’est signalé à ce jour. Il s’agit de bots qui cherchent une voie d’attaque, et d’une mesure de précaution du projet. Mélanger les deux revient à affirmer une perte qu’aucune source n’établit.

Ce que la mise à jour vers BTCPay Server 2.4.4 ferme réellement

Selon sa propre présentation, le projet s’attaque au déroulé décrit plus haut par deux voies.

Premièrement : la fin du mot de passe commun. La nouvelle image LND ne crée plus de portefeuilles avec un mot de passe par défaut partagé. Chaque portefeuille nouvellement créé reçoit son propre mot de passe aléatoire. Les portefeuilles existants encore réglés sur l’ancienne valeur par défaut sont basculés automatiquement au démarrage. Disparaît ainsi la part de l’attaque qui reposait sur une connaissance préalable.

Deuxièmement : le blocage en bordure de réseau. L’installation Docker bloque les voies non authentifiées de création et de déverrouillage du portefeuille dès le reverse proxy fourni. Par le chemin public par défaut, la fenêtre de redémarrage est donc close.

La version 2.4.4 a apporté d’autres changements susceptibles de vous toucher en exploitation, même s’ils n’ont rien à voir avec l’attaque. Les paiements NFC au moment de l’encaissement sont désormais désactivés d’origine et doivent être réactivés dans les réglages de la boutique. Les factures sans montant sont bloquées par défaut. La configuration des Boltcards via un lecteur de cartes relié à l’ordinateur a disparu ; BTCPay Server ouvre à la place l’application correspondante. Qui utilise le raccordement WHMCS a besoin, en raison d’une modification non rétrocompatible, de la version 4.0.0 du module complémentaire et d’une clé d’API nouvellement créée. Les utilisateurs de boutique invités doivent d’abord accepter leur invitation. Et dans le module de caisse, la possibilité de transmettre une adresse de notification propre à chaque requête a disparu ; c’est celle enregistrée dans le module qui s’applique.

L’installation Docker standard a fait dans le même temps un bond plus important : Bitcoin Core passe de 29.2 à 31.1, LND à 0.21.3-beta. La prise en charge de Bitcoin Knots a été retirée après que Knots a, selon le projet, suivi une chaîne qui s’est séparée de la chaîne principale. Qui emploie Knots délibérément devrait lire cela avant la mise à jour, et non après. S’y ajoute un rattachement plus étroit à la machine hôte : au lieu d’un large accès SSH, le conteneur applicatif ne reçoit plus qu’une clé pour une courte liste de commandes d’administration autorisées.

Pourquoi votre propre règle de reverse proxy reste intacte après la mise à jour

Voici le cœur du sujet, et c’est la phrase que le projet écrivait déjà en août : une mise à jour de BTCPay Server ne ferme aucune voie d’accès que vous gérez séparément. Une redirection dans votre propre reverse proxy, un port redirigé dans votre routeur, un service Tor créé de votre main — la mise à jour ne les connaît pas et ne peut pas les retirer.

L’instruction du projet est par conséquent sans équivoque : n’exposez pas l’interface LND sur le réseau à la main via un reverse proxy à vous. Si vous l’avez déjà fait, retirez cet accès et mettez votre serveur à jour. Les deux, à lire dans cet ordre, non comme une alternative.

Qui était déjà exposé en août par une voie personnelle devrait en outre renouveler les justificatifs de son nœud. La mise à jour vers 2.4.2 a recréé automatiquement les macaroons de l’installation standard ; cela ne vaut pas pour les chemins gérés par vos soins. Vous connaissez la même logique dans le cas de la faille Core Lightning de fin août, que nous avons décortiquée dans cette analyse de la faille Core Lightning : l’hypothèse dangereuse n’est jamais la faille elle-même, mais la croyance qu’un saut de version règle tout le reste.

L’accès Lightning externe est de retour, mais uniquement sur activation explicite

Pour beaucoup d’opérateurs, la désactivation d’août a été douloureuse, car elle supprimait aussi la voie légitime : un portefeuille mobile comme Zeus pilotant son propre nœud depuis l’extérieur. Le projet ne l’a jamais contesté et a annoncé en septembre un retour en bon ordre.

L’état d’aujourd’hui : une modification du pilotage des routes a été intégrée le 11 septembre et offre une possibilité prise en charge pour l’accès à distance, tandis que les interfaces de LND et de Core Lightning restent désactivées d’origine. C’est la différence décisive avec la situation ancienne : l’accès existe, mais vous devez l’activer sciemment, et il passe alors par le chemin entretenu par le projet plutôt que par votre bricolage.

Concrètement, pour vous : si vous avez besoin d’un accès à distance, utilisez l’interrupteur prévu et ne construisez plus de redirection personnelle. Et profitez-en pour vérifier quel portefeuille de votre téléphone doit réellement avoir accès à votre nœud. Quels portefeuilles logiciels prennent en charge quels modes de connexion, c’est le comparatif des portefeuilles logiciels lié plus bas qui le dit ; tous n’offrent pas les mêmes niveaux de droits, et un accès à distance avec un macaroon restreint est nettement plus inoffensif qu’un accès avec le passe-partout.

La liste de contrôle pour les opérateurs : ce que vous traitez aujourd’hui

Dans l’ordre, et que vous vous sentiez concerné ou non :

1. Déterminer la version. La mouture en service figure dans le pied de page de l’espace d’administration. Si elle est inférieure à 2.4.4, c’est votre premier geste.
2. Mettre à jour. Pour une installation Docker via Server Settings › Maintenance › Update. Pour une installation gérée autrement, par votre voie habituelle.
3. Chercher vos propres redirections. Parcourez votre configuration de proxy et guettez toute règle qui expose vers l’extérieur quoi que ce soit sous /lnd-rest/. Pensez aussi aux ports redirigés dans le routeur et aux services Tor créés par vos soins.
4. Retirer les voies trouvées. Non pas les commenter et les laisser en place, mais les supprimer et recharger le service.
5. Renouveler les droits si votre nœud a été joignable par un chemin géré par vos soins. Créer de nouveaux macaroons, invalider les anciens, reconfigurer les connexions enregistrées dans les portefeuilles mobiles.
6. Reconfigurer l’accès à distance si vous en avez besoin, via le réglage prévu plutôt que par des règles à vous.

Si le temps vous manque pour traiter proprement les points trois et quatre, le conseil de l’avis d’août reste valable dans son esprit : un nœud injoignable ne peut pas non plus être sondé. Mieux vaut quelques heures sans accès à distance qu’un point d’accès ouvert tout un week-end.

Comment savoir si votre nœud LND a été compromis

Le projet a publié pour l’incident d’août une routine de vérification qui vaut également ici. Cherchez dans votre nœud des paiements que vous n’avez pas déclenchés. Guettez les fermetures de canaux que vous n’avez pas initiées et les contreparties qui vous sont inconnues. Rapprochez votre solde on-chain et vos soldes de canaux de vos propres relevés. Tout ce que vous ne pouvez pas expliquer est une raison de chercher plus loin, non une raison de vous rassurer.

Une remarque de cadrage, pour qu’aucune panique ne naisse ici : une prise de contrôle par la voie observée en septembre n’a été signalée par personne à ce jour. La vérification relève de la diligence, non du constat de dégâts.

À considérer séparément, un troisième incident que le projet révèle dans la même communication : son serveur auto-hébergé de construction des modules complémentaires a été compromis, découverte faite le 2 septembre. Selon la présentation du projet, seuls les développeurs de modules sont concernés, non leurs utilisateurs. Les modules publiés n’ont, après vérification, pas été remplacés par des moutures malveillantes, et tous les jetons d’accès ont été renouvelés. Les adresses électroniques enregistrées étaient probablement consultables ; qui y est inscrit devrait s’attendre à des tentatives d’hameçonnage dans les semaines à venir et traiter les messages inattendus en conséquence.

Ce que l’incident signifie pour les commerçants allemands acceptant le bitcoin

En Allemagne, BTCPay Server est employé avant tout par de petits commerçants, des artisans, des associations et des boutiques en ligne qui veulent accepter le bitcoin sans intermédiaire. L’attrait tient à ce que le paiement arrive directement dans le portefeuille du commerçant. Aucun prestataire ne détient les fonds entre-temps.

Cette conception a un revers que le cas présent met en scène : là où personne ne s’interpose, personne non plus n’est responsable, ne bloque ni ne rembourse. Chez un prestataire conservateur, une attaque serait son problème. Sur votre propre serveur, elle est le vôtre. La responsabilité des mises à jour, des voies d’accès et de la répartition entre solde d’exploitation et réserve vous revient intégralement.

Il en découle une règle d’exploitation toute simple, valable indépendamment de chaque vulnérabilité particulière : sur le nœud ne reste que ce dont le trafic de paiement courant a besoin. Tout ce qui dépasse part régulièrement vers une conservation non reliée au réseau. Qui automatise ce transfert et l’effectue chaque semaine plutôt que chaque trimestre limite le dommage de tout incident futur à une somme maîtrisable.

Registres et fiscalité : ce que le fisc exige pour les paiements en bitcoin

Un point qui passe volontiers à la trappe dans les sujets de sécurité, mais qui vous rattrapera au plus tard lors du prochain contrôle : si votre entreprise accepte le bitcoin en paiement, l’encaissement est une recette d’exploitation. Ce qui fait foi, c’est la valeur en euros au moment de l’encaissement, et cette valeur doit être justifiée. Le délai de détention d’un an de l’article 23 de la loi allemande relative à l’impôt sur le revenu, qui peut exonérer les ventes privées, ne joue pas pour les actifs d’entreprise. Les gains et les pertes d’une vente ultérieure restent dans l’entreprise et relèvent de l’article 15 de la même loi.

Du point de vue de la TVA, la situation est tranchée de longue date : la Cour de justice de l’Union européenne a jugé dans l’affaire C-264/14 que l’échange de monnaie conventionnelle contre du bitcoin et inversement est exonéré de TVA ; le ministère fédéral allemand des Finances l’a transposé pour l’Allemagne par une circulaire du 27 février 2018. Votre livraison ou votre prestation proprement dite reste imposable indépendamment de cela, mesurée en euros.

Concrètement : il vous faut, pour chaque paiement, le moment, le montant en bitcoin, le cours en euros retenu et la provenance de ce cours. BTCPay Server conserve ces indications dans ses données de facturation et permet de les exporter. Servez-vous-en avant qu’un déménagement de serveur ou un incident ne rende la base inutilisable. Que les écritures soient soumises à une obligation de conservation et que l’accès doive rester possible pendant tout le délai de conservation découle de l’article 147 du code fiscal allemand et vaut pour une base de données SQL comme pour un classeur.

Quand son propre nœud est rentable, et quand il ne l’est pas

Après deux avis de sécurité en cinq semaines, la question de savoir si l’effort reste proportionné est légitime. Une réponse honnête doit citer les deux côtés.

En faveur du nœud personnel : personne ne détient votre argent, personne ne peut geler votre compte et aucune commission par transaction ne part chez un prestataire. Pour de petits montants sur le réseau Lightning, la différence se sent, car un prélèvement en pourcentage sur un achat à deux euros serait disproportionné.

Contre lui pèse la charge d’exploitation, et elle est réelle. Il vous faut quelqu’un qui lise les avis de sécurité, applique les mises à jour et documente les voies d’accès. Si cette personne manque dans l’entreprise, un prestataire de paiement conservateur est le choix le plus honnête malgré ses commissions. Un nœud mal entretenu coûte plus cher que toute commission, et cela exactement une fois.

Une voie médiane qui fonctionne bien en pratique : un nœud propre pour l’activité quotidienne avec un solde limité, des transferts fixes vers la conservation hors ligne, et une entrée d’agenda qui vous oblige une fois par mois à lire les publications du projet. Les avis des dernières semaines auraient tous été vus à temps de cette manière.

Sécuriser BTCPay Server : ce qu’il faut en retenir

1. Passez à 2.4.4 et retirez vos propres redirections LND. La mise à jour seule ne suffit pas si vous avez construit une voie vers l’extérieur. Dans le même mouvement, ramenez le solde du nœud aux besoins de l’exploitation ; le reste relève d’une conservation sans connexion au réseau, telle que notre comparatif des portefeuilles matériels la met en regard.
2. Reconfigurez l’accès à distance si vous en avez besoin. Utilisez le réglage prévu plutôt qu’une règle de proxy à vous, et attribuez à cette occasion un macaroon aux droits restreints. Quel portefeuille mobile maîtrise quel mode de connexion et quels niveaux de droits, c’est notre comparatif des portefeuilles logiciels qui le montre.
3. Sauvegardez vos justificatifs de paiement avant de toucher au serveur. Exportez les données de facturation avec le moment, le montant et le cours en euros retenu. Qui s’en occupe en continu plutôt qu’une fois l’an trouvera les outils adaptés dans notre panorama des logiciels fiscaux et suiveurs de portefeuille.

Les deux sources primaires dans leur texte : l’annonce de BTCPay Server 2.4.4 du 8 septembre 2026 et l’avis de sécurité relatif à la version 2.4.2 du 7 août 2026.

(Au 16 septembre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)