Core Lightning, uno dei software per gestire un nodo della Lightning Network, aveva un difetto che permetteva di spegnere un nodo con un messaggio di rete costruito ad arte. Lo ha reso pubblico lo sviluppatore Nishant Bansal, che il 24 ottobre 2026 ha riproposto la divulgazione in un post su Delving Bitcoin. Le versioni dalla 25.02 alla 26.04 andavano in crash davanti a un annuncio di canale che indicava lo stesso nodo come entrambi gli estremi, e ricadevano nel crash a ogni riavvio. La correzione è nella versione 26.04.1, uscita il 25 aprile 2026.
La vicenda è stata ripresa il 30 ottobre dalla newsletter Bitcoin Optech #429. Qui si ricostruisce cosa scrive l’autore, confrontato con la correzione su GitHub e con la specifica BOLT, lo standard che descrive come dialogano i nodi Lightning.
Core Lightning: cosa succedeva con l’annuncio di canale falso
I nodi Lightning conoscono la mappa dei canali grazie ai messaggi di gossip della specifica BOLT 7. Un messaggio channel_announcement nomina i due nodi che gestiscono il canale, chiamati node_id_1 e node_id_2. La specifica chiedeva a chi lo invia di ordinarli in modo che il primo fosse il minore in ordine lessicografico, ma non diceva nulla a chi lo riceve: lo ricorda la proposta BOLTs #1333, che scrive di aver richiesto l’ordine per chi scrive e di averlo omesso per chi legge.
Secondo Bansal, Core Lightning non verificava che i due identificativi fossero diversi. Un annuncio con lo stesso nodo da entrambe le parti, firmato e collegato a un output 2-di-2 non speso, superava i controlli e veniva scritto sul disco, nel file gossip_store. Quando gossipd, il processo che gestisce il gossip, lo caricava nel grafo in memoria, aggiungeva il nodo due volte e faceva scattare una verifica interna contro i duplicati. Il processo si fermava e, poiché lightningd considera il fatto grave, si spegneva l’intero nodo.
| Versione di Core Lightning | Comportamento con l’annuncio autoreferenziale |
|---|---|
| Prima della 25.02 | Lo accetta e lo inoltra, senza crash: la tabella dei nodi ammetteva duplicati |
| Dalla 25.02 alla 26.04 | Crash di gossipd e dell’intero nodo, ripetuto a ogni riavvio |
| Dalla 26.04.1 | Annuncio rifiutato: node_id_1 deve essere strettamente minore di node_id_2 |
Fonte della tabella: il post di Bansal, per il comportamento delle versioni, e la release v26.04.1 per il rifiuto dell’annuncio; il dettaglio «strettamente minore» è nel post di Bansal e in Optech.
Perché riavviare il nodo non bastava
Il nodo non si riprende da solo perché l’annuncio finisce sul disco prima di essere caricato. Al riavvio gossipd rilegge lo stesso record e si ferma di nuovo, quindi il nodo resta spento finché l’operatore non cancella il record a mano. Secondo l’autore, aggiornare il software da solo non elimina un record già memorizzato.
Un nodo fermo non controlla la blockchain. Bansal avverte che in quel periodo può perdere la trasmissione di una commitment revocata da parte di un peer (la versione vecchia di un canale, che un partner scorretto potrebbe pubblicare) o un HTLC (pagamento in sospeso) da reclamare prima della scadenza, con fondi a rischio. Dopo la pulizia, aggiunge, l’attaccante può rimandare lo stesso annuncio senza altri costi finché l’output resta non speso.
Quanto costava l’attacco
Il costo, scrive l’autore, si limitava alle commissioni on-chain. L’attaccante finanzia un output P2WSH 2-di-2 di cui controlla entrambe le chiavi, costruisce un annuncio con un nuovo identificativo di nodo come entrambi gli estremi e lo firma con quella chiave e con le due chiavi di finanziamento. Aspetta che l’output abbia 6 conferme, poi lo invia al bersaglio dopo l’handshake BOLT 8 e lo scambio dei messaggi init. I fondi restano sotto il suo controllo.
Non serve collegarsi a ogni vittima. Bansal e Optech osservano che le versioni di Core Lightning precedenti alla 25.02 accettano e inoltrano un annuncio simile senza andare in crash, quindi possono portarlo a nodi vulnerabili che l’attaccante non raggiunge direttamente.
Dalla segnalazione alla divulgazione: la cronologia
| Data | Evento |
|---|---|
| 23 aprile 2026 | Segnalazione privata a Core Lightning |
| 24 aprile 2026 | Correzione unita al codice (PR #9082) |
| 25 aprile 2026 | Rilascio della v26.04.1 |
| 4 maggio 2026 | La specifica BOLT 7 aggiunge il requisito per chi riceve (BOLTs #1333) |
| 24 ottobre 2026 | Divulgazione pubblica da parte di Bansal |
| 30 ottobre 2026 | La newsletter Bitcoin Optech #429 la riassume |
Le date di segnalazione sono quelle dichiarate da Bansal; quelle di correzione, rilascio e specifica risultano dalle pagine GitHub. Le note della v26.04.1 presentano la modifica come rispetto della specifica BOLT, che evita la corruzione del gossip store e lo stress sui lettori, senza parlare di vulnerabilità. La descrizione come attacco DoS (denial of service, negazione del servizio) arriva con la divulgazione di ottobre.
Come è stato trovato e cosa fare
Il difetto è emerso da un fuzz target, un programma che manda al software messaggi validi e malformati per farlo cedere. Quello per il gossip di Core Lightning è stato proposto poi con la PR #9115: un annuncio autoreferenziale generato dal fuzzer ha fatto scattare la verifica sui duplicati, e la prova su un nodo di test ha mostrato il crash ripetuto al riavvio.
Chi gestisce un nodo Core Lightning dovrebbe passare all’ultima versione, che al 30 ottobre 2026 è la v26.06.9, uscita il 7 ottobre 2026. Tra le lezioni indicate da Bansal ci sono due regole di progettazione: validare gli input non fidati prima di salvarli e controllare sul lato ricevente ciò che la specifica impone a chi invia. BitcoinLive24 aveva già scritto di un altro avviso di sicurezza di Core Lightning e delle due falle DoS di Eclair.
Scarica l’app BitcoinLive24 per ricevere le novità sulla sicurezza della Lightning Network.
Domande frequenti sulla falla di Core Lightning
Quali versioni di Core Lightning erano vulnerabili?
Dalla 25.02 alla 26.04, secondo il post di Bansal. La correzione è nella v26.04.1 del 25 aprile 2026: chi ha quella versione o una successiva ha la correzione.
Basta aggiornare per risolvere se il nodo è già in crash?
No: l’autore precisa che l’aggiornamento non cancella il record già salvato nel gossip store, che va rimosso a mano dall’operatore.
L’attacco costava molto?
Secondo Bansal, no: bastava un output 2-di-2 controllato dall’attaccante, quindi il costo erano solo le commissioni on-chain, e i fondi restavano nelle sue mani.
Anche gli altri software Lightning sono coinvolti?
Le fonti consultate riguardano solo Core Lightning. La modifica alla specifica BOLT 7 aggiunge però lo stesso requisito sull’ordine degli identificativi anche per chi riceve; le fonti non indicano però altre implementazioni vulnerabili.
