Eclair, il software per nodi della Lightning Network sviluppato da ACINQ, aveva due falle di tipo denial of service (DoS, attacchi che mettono fuori uso un servizio sovraccaricandolo) sfruttabili da qualsiasi peer connesso. Le due vulnerabilità, divulgate il 24 settembre 2026 dal ricercatore Matt Morehouse, riguardano la versione 0.13.1 e quelle precedenti; la correzione è nella v0.14.0, rilasciata il 21 maggio. La newsletter Bitcoin Optech #425 del 2 ottobre le riprende e invita chi usa una versione più vecchia ad aggiornare.
Cosa è successo: due falle, nessuna perdita di fondi dimostrata
Il 24 settembre 2026 Morehouse ha reso pubbliche due vulnerabilità di Eclair nel progetto lnfuzz, siglate LNF-2026-0001 e LNF-2026-0002, valutate entrambe di gravità media. Secondo il suo annuncio su Delving Bitcoin, tutte e due sono corrette nella v0.14.0. Per sfruttarle l’attaccante non ha bisogno di aprire un canale: secondo Optech basta completare l’handshake BOLT 8, la fase iniziale con cui due nodi Lightning stabiliscono una connessione cifrata.
Nei test descritti nell’avviso della prima falla, un nodo Eclair con 2 core di CPU e 8 GB di RAM ha perso tutti i peer legittimi entro un minuto, l’API ha smesso di rispondere e l’elaborazione dei blocchi è rimasta indietro; con la seconda falla il nodo è andato offline in pochi secondi. Dopo il riavvio il nodo è tornato operativo senza perdite, ma l’attacco poteva essere ripetuto. L’autore precisa che non ha tentato di dimostrare un furto di fondi; per prudenza ipotizza però che un attacco prolungato renda difficile gestire gli eventi on-chain e possa mettere a rischio i fondi.
Le due falle: feature bit e compressione zlib
La prima falla (LNF-2026-0001) riguarda l’analisi dei feature bit, i bit con cui ogni nodo dichiara le funzioni supportate nel messaggio init. Secondo l’avviso lnfuzz, Eclair 0.13.1 e precedenti scorrevano il vettore un bit alla volta creando più oggetti in memoria per ciascuno: un singolo messaggio init di circa 64 KB generava circa 300 MB di movimentazione di memoria e occupava un thread fino a 300 millisecondi. Con poche decine di connessioni che ripetono il messaggio, tutti i peer venivano disconnessi in meno di un minuto e la memoria si esauriva in meno di cinque.
La seconda (LNF-2026-0002) nasce da una funzione rimasta in codice dopo essere stata abolita. Il protocollo (BOLT 7) ha eliminato la codifica zlib per le richieste di canali ad aprile 2022 e Eclair aveva smesso di inviarla lo stesso mese, ma continuava ad accettarla. Come spiega l’avviso dedicato, la decompressione non aveva limiti: un messaggio da 64 KB si gonfiava fino a 64 MB, circa 17 milioni di oggetti secondo il post su Delving, e un flusso di richieste simili metteva il nodo offline in pochi secondi.
| Falla | Causa | Effetto misurato | Correzione |
|---|---|---|---|
| LNF-2026-0001 | Analisi dei feature bit inefficiente | ~300 MB di memoria allocata e scartata, fino a 300 ms per messaggio da ~64 KB | PR #3264, in v0.14.0 |
| LNF-2026-0002 | Decompressione zlib senza limite | 64 KB inflazionati a 64 MB | PR #3263, in v0.14.0 |
Perché è importante per chi gestisce un nodo Eclair
Un nodo Lightning è un software sempre acceso che custodisce fondi in canali di pagamento, quindi un attacco che lo mette offline non è solo un fastidio. Dopo la correzione, secondo l’avviso, un singolo messaggio init di lunghezza massima viene elaborato in 1-2 millisecondi con circa 200 KB di memoria movimentata. Sul metodo, secondo Morehouse, la seconda falla è emersa da un’analisi di varianti assistita da un modello linguistico (LLM), eseguita dopo che il suo fuzzer smite aveva individuato la prima.
Il caso non è isolato. Un post su Delving Bitcoin del 1° ottobre descrive altre due DoS nel flusso di apertura dei canali, corrette dalla v0.14.1: una corsa critica (race condition) che lascia attori orfani in memoria, con una perdita di circa 1 MB al secondo se sfruttata di continuo (LNF-2026-0003, di gravità bassa secondo lnfuzz), e un bypass del limitatore dei canali in attesa, che secondo l’autore ha esaurito la memoria di un nodo con 4 GB di heap in circa 48 minuti. Sullo stesso fronte, BitcoinLive24 ha raccontato oggi l’avviso di Core Lightning sui nodi non aggiornati: sono software e vulnerabilità diversi. Per il contesto sulla sicurezza dei nodi, si veda anche la patch di sicurezza di Bitcoin Core 31.1.
Cronologia della divulgazione delle falle di Eclair
Secondo la cronologia pubblicata da lnfuzz, la prima falla è stata segnalata in privato ad ACINQ il 5 marzo 2026 e riprodotta il giorno dopo. Il 10 marzo le parti si sono accordate per rendere pubblico il problema circa sei mesi dopo l’arrivo della correzione, che è stata integrata il 17 marzo. La v0.14.0 di Eclair è uscita il 21 maggio e la divulgazione pubblica è arrivata il 24 settembre. Un punto che Optech sottolinea: la correzione della prima falla è confluita in un refactoring dell’analisi dei feature bit che non ne menzionava la vulnerabilità.
Cosa devono fare gli operatori Eclair
Le versioni da 0.13.1 in giù restano vulnerabili alle due falle finché non vengono aggiornate, e la v0.14.0 resta esposta ai problemi nell’apertura dei canali descritti sopra, corretti dalla v0.14.1. L’elenco delle release su GitHub mostra come più recente la v0.14.3 del 14 settembre 2026. Gli avvisi lnfuzz chiudono con la stessa raccomandazione tecnica: limitare il lavoro che un peer può imporre a un nodo, in modo che non costi all’attaccante meno di quanto costa alla vittima.
Per ricevere in tempo reale gli aggiornamenti su sicurezza e protocollo, scarica l’app BitcoinLive24.
Domande frequenti
Quali versioni di Eclair erano vulnerabili?
La 0.13.1 e quelle precedenti, per le due falle divulgate il 24 settembre. Entrambe sono corrette dalla v0.14.0, uscita il 21 maggio 2026.
Qualcuno ha perso fondi?
Gli avvisi non riportano perdite di fondi né attacchi nel mondo reale. Nel test l’autore ha messo offline un nodo senza perdite e precisa di non aver tentato di dimostrare un furto.
Cosa devo fare se uso Eclair?
Aggiornare alla v0.14.0 o successiva corregge le due falle divulgate il 24 settembre, come indicano gli avvisi e Bitcoin Optech; la v0.14.1 o successiva corregge anche i due problemi nell’apertura dei canali. Le release sono sulla pagina GitHub del progetto ACINQ.
