La mise à jour de sécurité de Bitcoin Lightning ferme une porte. Une faille critique de Linux demeure

Les opérateurs de Bitcoin Lightning utilisant un noyau Linux affecté et non corrigé restent exposés à une vulnérabilité critique après avoir mis à jour LND, le logiciel utilisé pour faire fonctionner leurs nœuds de paiement.

Les versions du 30 octobre, v0.20.7-beta et v0.21.6-beta, désactivent par défaut les écouteurs Multipath TCP, ou MPTCP. Cela ferme la route démontrée CVE-2026-98432 à travers ces écouteurs. Cela laisse la faille du noyau en place et ne couvre pas d'autres services sur la même machine.

Un autre service MPTCP exposé sur la même machine non corrigée peut préserver la route démontrée, même après que les écouteurs par défaut de LND aient changé.

Pourquoi la mise à jour de LND a des limites

La faille implique l'utilisation de mémoire libérée lors de la gestion des connexions TCP IPv4 dans Linux et peut permettre à un attaquant d'exécuter du code sur un hôte affecté. Ubuntu lui attribue un score CVSS 3.1 critique de 9.8.

Les notes des opérateurs de LND indiquent que Go 1.24 et versions ultérieures ont activé par défaut les écouteurs MPTCP sur Linux, ce qui a exposé LND 0.21.x sur ses ports pairs, gRPC et REST. Cela inclut les connexions du nœud à d'autres nœuds et ses interfaces d'application.

L'avis de l'équipe de sécurité de Go explique pourquoi ce changement ne peut pas terminer le travail. L'exploit démontré nécessite un écouteur MPTCP exposé, mais le bug du noyau est plus large. Des attaques similaires contre des systèmes sans écouteurs MPTCP peuvent être possibles ; l'avis ne prouve pas un exploit non-MPTCP démontré.

Go avertit également que désactiver MPTCP un programme à la fois est fragile. Un seul écouteur exposé restant laisse le système vulnérable à cette route, et des paramètres de socket explicites peuvent remplacer la configuration par défaut de Go.

Les avis décrivent un exploit Linux démontré, pas de preuves que des attaquants ont utilisé cette faille contre les nœuds LND ou volé du Bitcoin.

CryptoSlate a précédemment couvert les implications de la même CVE pour les validateurs Solana. Les corrections du canal Core Lightning et de la commande à distance signalées le 6 novembre concernent des failles d'application distinctes.

Le suivi Ubuntu, vérifié le 9 novembre et mis à jour pour la dernière fois le 7 novembre, a toujours étiqueté le paquet standard linux pour Ubuntu 24.04 LTS comme vulnérable, avec des travaux en cours dans 6.8.0-149.149. Son entrée pour Ubuntu 22.04 LTS portait le même statut pour 5.15.0-203.213.

La disponibilité des correctifs varie selon le paquet. Dans son avis du 2 novembre, Canonical a déclaré que les correctifs du noyau pour cette CVE étaient disponibles dans le dépôt -proposed pour les utilisateurs qui effectuent leurs propres tests d'acceptation du noyau, tandis que les tests de qualification se poursuivaient.

La newsletter de travail en cours d'Ubuntu pour la période du 1er au 7 novembre a également indiqué que certaines versions, y compris 24.04, avaient avancé vers -updates. Cette note plus large n'identifie pas chaque variante de noyau. Les opérateurs doivent donc vérifier la mise à jour disponible pour leur paquet de noyau exact plutôt que de déduire la disponibilité uniquement à partir du nom de version d'Ubuntu.

Le suivi illustre la distinction : il liste le paquet standard Ubuntu 26.10 linux comme corrigé dans 7.3.0-10.10, tandis que les variantes de noyau cloud, d'activation matérielle et autres ont des entrées séparées. Un statut corrigé pour un paquet ne peut pas régler le statut d'un autre.

La protection nécessite encore du travail sur l'hôte

Les mainteneurs de LND recommandent de mettre à jour l'application, de désactiver MPTCP sur l'hôte et d'installer un noyau corrigé dès que la distribution en met un à disposition.

LND ferme une route. Le noyau doit encore être réparé.

La mise à jour de LND change l'application. Réparer le noyau Linux partagé nécessite une mise à jour distincte de l'hôte. UN HÔTE, DEUX COUCHES DE MAINTENANCE Publication de l'application LND Autres services Applications séparées Noyau Linux partagé LND Autres services Noyau Linux partagé

Configurations cumulatives de l'hôte

Configurations cumulatives des hôtes LND mis à jour MPTCP désactivé Noyau corrigé en cours d'exécution
Configuration illustrative : Les écouteurs MPTCP par défaut de LND sont désactivés, mais un autre service en expose toujours un sur un hôte non corrigé.
Trafic MPTCP entrant LND MPTCP par défaut désactivé Autre service MPTCP exposé NOYAU LINUX PARTAGÉ Un défaut de noyau demeure Le noyau de l'hôte n'est toujours pas corrigé
Trafic MPTCP entrant LND MPTCP par défaut désactivé Autre service MPTCP exposé NOYAU LINUX PARTAGÉ Un défaut de noyau demeure Le noyau de l'hôte n'est toujours pas corrigé Un autre écouteur préserve le chemin.
Avec MPTCP désactivé dans les espaces de noms réseau pertinents, le chemin démontré est fermé. Le défaut de noyau sous-jacent demeure.
Trafic MPTCP entrant LND MPTCP par défaut désactivé Autre service MPTCP désactivé NOYAU LINUX PARTAGÉ Un défaut de noyau demeure Le noyau de l'hôte n'est toujours pas corrigé
Trafic MPTCP entrant LND MPTCP par défaut désactivé Autre service MPTCP désactivé NOYAU LINUX PARTAGÉ Un défaut de noyau demeure Le noyau de l'hôte n'est toujours pas corrigé L'atténuation MPTCP laisse le bogue en place.
Après l'installation et le démarrage d'un noyau corrigé, ce défaut de noyau est réparé. Le diagramme conserve l'atténuation MPTCP précédente.
Trafic MPTCP entrant LND MPTCP par défaut désactivé Autre service MPTCP désactivé NOYAU LINUX PARTAGÉ Ce défaut de noyau réparé Le noyau corrigé est en cours d'exécution
Trafic MPTCP entrant LND MPTCP par défaut désactivé Autre service MPTCP désactivé NOYAU LINUX PARTAGÉ Ce défaut de noyau réparé Le noyau corrigé est en cours d'exécution La réparation s'applique à ce défaut de noyau.

Mettez à niveau LND, traitez d'autres écouteurs MPTCP et espaces de noms réseau, puis installez et démarrez un noyau corrigé.

Configurations illustratives, pas de tests d'un nœud en direct ou d'un enregistrement d'attaques. La désactivation de MPTCP couvre uniquement le chemin démontré ; le bogue est plus large. L'état désactivé suppose que les espaces de noms réseau pertinents sont couverts. D'autres vulnérabilités sont hors de portée.
Sources et preuves

Sources

1. Publication de sécurité LND v0.20.7
2. Publication de sécurité LND v0.21.6
3. Conseils pour les opérateurs LND et Docker
4. Avis de l'équipe de sécurité Go
5. Conseils de mise à jour et de redémarrage du noyau Canonical

Faits supplémentaires

• LND v0.20.7-beta et v0.21.6-beta, publiés le 30 octobre, désactivent par défaut les écouteurs MPTCP pour fermer le chemin d'exploitation démontré CVE-2026-98432 via LND ; ils ne réparent pas le noyau Linux. [1] [2]
• L'équipe de sécurité Go dit que l'exploitation démontrée nécessite un écouteur MPTCP exposé, mais le bogue sous-jacent n'est pas spécifique à MPTCP et des attaques similaires contre des systèmes sans tels écouteurs peuvent être possibles. [4]
• L'équipe de sécurité Go avertit que désactiver MPTCP programme par programme est fragile : un écouteur MPTCP exposé restant laisse l'hôte vulnérable au chemin démontré, et des choix par socket peuvent remplacer le défaut GODEBUG. [4]
• Une mise à niveau de LND ne protège pas d'autres services sur la même machine ; les mainteneurs de LND conseillent de désactiver MPTCP sur l'hôte et d'installer un noyau corrigé dès que la distribution en fournit un. [2] [3]
• Les conseils de LND utilisent sudo sysctl -w net.mptcp.enabled=0 et une configuration sysctl persistante pour désactiver MPTCP sur l'hôte ; le paramètre est par espace de noms réseau, donc les déploiements Docker nécessitent une attention séparée à l'espace de noms. [3]
• Canonical conseille de vérifier le noyau en cours d'exécution avec uname -r ; après avoir installé les mises à jour de sécurité du noyau Linux, un redémarrage est requis. [5]

Méthode

Schéma des configurations cumulatives des opérateurs utilisant le comportement documenté de LND et Go. Les chemins montrent le chemin MPTCP démontré, pas les transferts Bitcoin ou le trafic mesuré. L'état final nécessite l'installation d'un noyau corrigé et un redémarrage dans celui-ci.

Portée

Configurations illustratives, pas de tests d'un nœud en direct ou d'un enregistrement d'attaques. La désactivation de MPTCP couvre uniquement le chemin démontré ; le bogue est plus large. L'état désactivé suppose que les espaces de noms réseau pertinents sont couverts. D'autres vulnérabilités sont hors de portée.
Infographie par CryptoSlate

Leur guide utilise sudo sysctl -w net.mptcp.enabled=0 pour le paramètre hôte, avec une configuration persistante pour le conserver. Le paramètre s'applique par espace de noms réseau, donc les déploiements Docker nécessitent une attention séparée à la configuration réseau du conteneur. Changer l'hôte seul ne remplace pas la vérification de cette portée.

Les opérateurs qui ne peuvent pas mettre à niveau LND immédiatement peuvent démarrer leur binaire existant avec GODEBUG=multipathtcp=0 pour désactiver les écouteurs MPTCP par défaut de Go. Les mainteneurs mettent en garde contre la réactivation de ce paramètre par défaut avant de patcher le noyau.

Canonical conseille de vérifier le noyau réellement en cours d'exécution avec uname -r. Après avoir installé sa mise à jour de sécurité du noyau, un redémarrage est nécessaire. Un binaire LND mis à niveau et un paquet de noyau installé sont des étapes différentes ; compléter la réparation du système d'exploitation nécessite d'exécuter le noyau patché.