Lightning Network: il 71% dei 550 nodi LND esposti ad agosto usa ancora software vecchio, stima un preprint

Due mesi dopo la pubblicazione, l’11 agosto, di una serie di falle di sicurezza di LND da parte di Lightning Labs, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il 71% dei 550 nodi pubblici di Lightning Network che allora usavano una versione esposta di LND era ancora fermo su una di esse. Lo sostiene un preprint di Saurabh Kumar, di Bitcoin Data Labs, con dati fino al 13 ottobre. Quel 71% è la quota del gruppo esposto e non della rete. Quei nodi erano il 14,9% dei nodi LND attivi e detenevano il 6,4% della capacità dei canali LND attivi.

La cifra è l’inferenza di un singolo ricercatore a partire da dati pubblici, comparsa su arXiv il 21 ottobre e non sottoposta a revisione paritaria. Non abbiamo trovato alcuna misurazione indipendente che la riproduca. Né nel documento né negli avvisi di Lightning Labs compare un furto collegato a queste falle di LND.

In cifra tonda, circa 390 dei 550 nodi sono rimasti dov’erano (calcolo nostro, dalle percentuali del documento). Un altro 10% era passato a una linea di rilascio più recente e il 20% non risultava più attivo. Le quote sommano 101% perché sono arrotondate. Le correzioni erano vecchie: LND 0.19.0-beta è uscito il 22 maggio 2025, 446 giorni prima della comparsa degli avvisi.

Come lo studio stabilisce quali nodi LND sono esposti

LND è il software dietro la maggior parte dei nodi pubblici di Lightning, il livello di pagamento costruito sopra bitcoin (la nostra guida a reti layer 1 e layer 2 spiega la differenza). Il gossip di Lightning, i messaggi con cui i nodi si annunciano, non contiene la versione del software. Nessuno può quindi limitarsi a contare le versioni, come fanno i crawler sulla rete peer-to-peer di Bitcoin.

Il metodo di Kumar usa i feature bit, i contrassegni che ogni nodo dichiara. Ha costruito una tabella dei bit impostati da ogni versione di LND, Core Lightning (CLN), Eclair e LDK, poi l’ha confrontata con 814 istantanee giornaliere del grafo pubblico, scattate dal suo nodo LND da maggio 2023 fino al limite del 13 ottobre. Il risultato è una «linea di rilascio» per ogni nodo, che può comprendere più versioni. Le versioni di correzione all’interno di una linea non si vedono.

Il numero 550 indica la dimensione di un gruppo preciso, mostrato nella Figura 7 del documento: i nodi LND attivi su una linea precedente alla 0.19 nell’ultima istantanea prima della divulgazione. «Attivo» significa che un peer aveva abilitato un canale verso il nodo e lo aveva aggiornato nei 14 giorni precedenti. I nodi non annunciati, tra cui la maggior parte dei wallet mobili, restano fuori dal conteggio. Resta fuori anche una flotta gestita di piccoli nodi LND, arrivata a 1.781 nodi attivi ed esclusa perché i suoi nodi si muovono all’unisono. Contando quella flotta, il 14,9% scenderebbe al 12,9%.

Verificare il metodo è più difficile per LND che per CLN. Alcuni nodi CLN indicano la propria versione nell’alias, e lì la linea dedotta era esatta per 132 coppie nodo-linea su 136. Nessun nodo LND nei suoi dati lo fa. Per LND il documento si affida a prove indirette: le linee tornavano indietro solo nello 0,7% dei cambi osservati, e dal 97% al 99,7% dei nodi che si sono spostati subito dopo l’uscita di una nuova linea LND su una piattaforma sono approdati alla linea che quella piattaforma aveva rilasciato.

Kumar elenca da sé i punti deboli. Un nodo che si aggiorna senza riavviarsi, o il cui nuovo annuncio non raggiunge mai il nodo dell’autore, conserva i vecchi bit, e questo spinge l’esposizione verso l’alto. Gli operatori possono anche disattivare alcune funzioni, così che una linea più recente sembri più vecchia. I limiti rigorosi del documento per il giorno della divulgazione vanno dal 5% al 15% dei nodi LND attivi: il 5% conta solo i nodi per cui ogni linea possibile è interessata, quindi il 14,9% sta in cima a quell’intervallo. In senso opposto, il 77% dei nodi esposti aveva firmato un annuncio recente con i vecchi bit nei 14 giorni prima della divulgazione, perciò la maggior parte non era costituita da voci obsolete.

Le falle vanno dal denial of service alla possibile perdita di fondi

L’indice degli avvisi di Lightning Labs elenca dieci avvisi LND datati 11 agosto, tre classificati T1 High e sette T3 Low. Il documento ne raggruppa sei come denial of service. Sono gli elementi T3 corretti nella 0.19.0, in cui un peer può esaurire le risorse di un nodo o disturbarne il gossip. Un’altra falla corretta nella stessa versione è di natura diversa.

Quella falla è il mancato sweep di primo stadio degli HTLC. Gli HTLC sono i pagamenti condizionati che attraversano i canali Lightning. Su LND 0.18, un nodo con la riserva predefinita del wallet poteva saltare lo sweep on-chain di un HTLC in uscita superiore a circa 50.000 sat dopo una chiusura forzata. Un partner di canale poteva instradare un grosso HTLC attraverso la vittima, chiudere il canale con la forza e incassare il valore alla scadenza. Lightning Labs lo valuta come perdita di fondi per singola vittima e dice che la versione non ostile del difetto è stata osservata nella pratica, con commissioni di sweep molto alte e chiusure forzate a catena. L’avviso non segnala alcun attacco.

Altre falle più vecchie stanno dietro lo stesso confine della 0.19. Il ricercatore di sicurezza Matt Morehouse ha reso noto il 4 dicembre 2025 che LND 0.18.5 e precedenti permettevano agli attaccanti di rubare i fondi dei nodi attraverso una debolezza nello sweeper. Due altri avvisi T1 della serie di agosto, lo sfruttamento update_fee per bruciare commissioni e il fallimento eccessivo degli HTLC, erano stati corretti nella 0.18.3 e nella 0.18.0, e al limite dei dati solo il 4% circa dei nodi LND attivi restava sulle versioni interessate.

Fonte: preprint di Kumar, Tabella III, classificazioni di Lightning Labs. L’esposizione conta i nodi LND attivi su una linea di rilascio interessata, flotta gestita esclusa, ogni riga riferita al proprio giorno di divulgazione. Le ultime due righe mostrano perché la 0.19 non è un traguardo.

Quanti bitcoin siano esposti non si sa

Il documento fornisce quote per i nodi esposti, non importi, e noi non le abbiamo convertite in dollari. La sua cifra principale sulla capacità è il 6,4% della capacità LND attiva nel giorno della divulgazione. Solo per dare un’idea di scala, indica in 8.300 BTC l’intera capacità LND attiva al 7 dicembre 2025, una data diversa. I nodi esposti sono piccoli: la loro quota di capacità è circa la metà della loro quota di nodi. Per la sola falla di sweep con perdita di fondi, che tocca solo la linea 0.18, il documento stima l’esposizione al 10% dei nodi LND attivi e al 5% della capacità alla divulgazione.

Un nodo su una linea interessata non è automaticamente attaccabile. «Esposizione non significa sfruttabilità», scrive il documento nell’elenco dei limiti. Diversi avvisi richiedono un canale con la vittima, una configurazione particolare o connessioni in ingresso. Il documento non conta quanti dei 550 soddisfino queste condizioni. Kumar sostiene comunque il punto dei piccoli nodi dall’altro lato: la quota di capacità è bassa, scrive, ma «ognuno custodisce i fondi del suo operatore». Aggiunge che, dove un attacco richiede un canale con la vittima, questi nodi sono anche i più economici da raggiungere.

Core Lightning è un discorso a parte. Il documento afferma che i manutentori del progetto hanno segnalato attacchi a nodi CLN non aggiornati entro ottobre. L’affermazione è del documento, noi non l’abbiamo confermata altrove, e riguarda un software diverso: non prova che alcun nodo LND sia stato attaccato.

Nulla di ciò che abbiamo letto collega queste falle di LND ai furti dagli hot wallet di BTCPay Server che abbiamo raccontato all’inizio di lunedì, i quali riguardano wallet su server BTCPay gestiti direttamente dai commercianti.

I nodi Lightning si aggiornano quando le piattaforme rilasciano, non quando escono gli avvisi

La scoperta più duratura riguarda il comportamento. Metà dei nodi LND su una linea più vecchia è passata a una nuova versione entro 88 giorni. Il quarto più piccolo per capacità ha impiegato una mediana di 135 giorni, il quarto più grande 75, e i nodi già indietro di più di una linea avevano probabilità circa cinque volte inferiori di spostarsi in una data settimana.

Le tre maggiori ondate di aggiornamenti, da 262 a 385 nodi ciascuna, sono arrivate circa un giorno dopo che l’app store di Umbrel aveva pubblicato una nuova versione di LND. Almeno l’87% di quei nodi ha firmato un nuovo annuncio entro 48 ore dall’integrazione di Umbrel, e le versioni di Umbrel arrivavano da 19 a 41 giorni dopo quelle di LND. Da giugno 2025, il 17% degli aggiornamenti LND è caduto nelle 48 ore successive al rilascio di una piattaforma, finestre che coprono il 4,4% del tempo. Sono stime per difetto, perché solo Umbrel e BTCPay Server si sono potuti datare, e il gossip non indica su quale piattaforma giri un nodo.

Gli avvisi hanno pesato molto meno. Il tasso settimanale di uscita dei nodi dalle linee interessate è stato dell’1,4% sia prima sia dopo l’11 agosto. Il documento è prudente su questo punto: tolti gli spostamenti seguiti al rilascio di sicurezza di BTCPay del 7 agosto, il rapporto è 1,30 con un intervallo di confidenza al 95% da 0,56 a 3,03, quindi un effetto modesto non si può escludere. Sulle 12 divulgazioni che ha potuto testare, nove delle quali per LND, solo quella di CLN del 19 luglio ha accelerato chiaramente gli aggiornamenti, e solo tra i nodi indietro di una linea.

La spiegazione più probabile per Kumar è la tempistica. La correzione di CLN per gossipd aveva 90 giorni al momento della divulgazione, e l’esposizione di CLN è scesa dal 66,6% dei nodi attivi al 24,2% entro il limite dei dati, con il 46% di quei nodi aggiornato e il 32% non più attivo. La correzione di LND ne aveva 446, quindi i nodi rimasti da avvertire erano quelli che avevano saltato ogni rilascio da allora. Il divario mediano tra correzione e divulgazione negli avvisi studiati è di 256 giorni, un ritardo pensato per lasciare agli operatori il tempo di aggiornarsi prima che gli attaccanti sappiano cosa cercare. Una coorte precedente racconta la stessa storia: dei 1.284 nodi LND esposti alla divulgazione di dicembre di Morehouse, il 55% era ancora su una linea interessata quattro mesi dopo.

Cosa possono controllare ora gli operatori di nodi LND

La maggior parte dei wallet Lightning mobili era fuori da questo studio, che dice quindi poco sui loro utenti. Chi gestisce un nodo LND pubblico può leggere la versione direttamente sulla macchina, cosa che nessuna inferenza dal gossip può eguagliare.

L’avviso di Lightning Labs chiede di aggiornare alla v0.19.0-beta o successiva, che elimina le sette falle corrette in quella versione. È un livello minimo. Secondo la politica sul ciclo di vita dell’azienda, solo le due linee più recenti sono mantenute, oggi 0.21 e 0.20. La linea 0.19 ha raggiunto la fine del supporto il 5 giugno 2026, con l’uscita della 0.21.0, e non riceve più correzioni di sicurezza. Gli avvisi del 21 settembre elencano già falle che toccano la 0.19 con correzioni solo dalla linea 0.20 in poi.

Nemmeno le due linee mantenute sono identiche. La falla della chiusura cooperativa nella tabella permette a una controparte di pubblicare un commitment revocato dopo una riorganizzazione di un blocco, con fondi a rischio, secondo la divulgazione di Bastien Teinturier, che non conosce utenti colpiti. Il suo messaggio data la correzione alla «20.0». Le note di rilascio di LND la collocano nella 0.21.0, come fa il documento, e il codice aggiunto da quella modifica è assente dal tag v0.20.7 quando l’abbiamo letto il 2 novembre. Su questa lettura, solo la linea 0.21 la contiene.

Le ultime versioni di LND, v0.21.6-beta e v0.20.7-beta del 30 ottobre, disattivano inoltre per impostazione predefinita i listener MPTCP a causa della falla del kernel Linux CVE-2026-98432. Le note di rilascio la definiscono una mitigazione e dicono che la patch del kernel è l’unica soluzione. Chiedono agli operatori Linux di disattivare MPTCP anche sul sistema e di installare un kernel corretto non appena la loro distribuzione lo rilascia; Windows e macOS non sono interessati. Chi usa Umbrel o box simili riceve LND quando la piattaforma lo pubblica, quindi la versione dell’app store è quella da controllare.

Chi usa Eclair ha un compito a parte. La falla delle richieste da browser corretta a ottobre richiedeva anch’essa un intervento dell’operatore, e la versione attuale è ora la v0.14.6 del 27 ottobre, che ACINQ descrive come un rafforzamento della sicurezza e di cui raccomanda l’installazione.

Cosa confermerebbe o smentirebbe il 71%

L’autore dice che codice e dati aggregati sono pubblici, insieme a uno script che ricalcola ogni numero, mentre le istantanee giornaliere grezze sono disponibili su richiesta. Una riesecuzione indipendente da un secondo punto di osservazione, o una revisione paritaria, metterebbe alla prova la cifra. Servirebbe anche una dichiarazione di Lightning Labs o di Umbrel: nelle fonti che abbiamo aperto non ne abbiamo trovata nessuna sul documento. Kumar pubblica solo dati aggregati, senza elenco dei singoli nodi, perché il suo metodo individua nodi che usano software vulnerabile.