Eclair, la patch che impedisce alle pagine web di comandare un nodo Lightning Network

Aggiornamento del 21 ottobre 2026, 16:45 UTC: ACINQ ha rilasciato Eclair v0.14.5 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 20 ottobre, cinque giorni dopo la v0.14.4. È un’altra patch di rafforzamento della sicurezza, che ringrazia per la divulgazione responsabile due ricercatori che firmano come Nuhiat-Arefin e mptfire, e ACINQ avverte che alcuni dei problemi «possono essere sfruttati da nodi malevoli». Le note di rilascio non descrivono nessuna delle falle, non indicano CVE né un elenco delle versioni interessate, e non risultano attacchi o perdite, come ha osservato CryptoSlate il 21 ottobre. I manutentori non hanno collegato le nuove correzioni al problema del browser descritto più sotto. Chi aveva già installato la v0.14.4 deve quindi aggiornare di nuovo. La procedura non cambia: si verificano la firma e il file SHA256SUMS, si ferma Eclair, si installa la v0.14.5 e si riavvia, senza chiudere alcun canale.

ACINQ ha pubblicato Eclair v0.14.4, una versione che impedisce alle pagine web di inviare comandi a un nodo Lightning Network attraverso il browser di chi lo gestisce. Uscito il 15 ottobre 2026 alle 19:30 UTC, l’aggiornamento fa sì che l’API di controllo del nodo rifiuti qualsiasi richiesta con un’intestazione Origin, che i browser aggiungono a ogni richiesta tra siti diversi e a ogni richiesta che non sia un semplice GET o HEAD. Finora, secondo le note di rilascio, qualunque pagina web visitata dall’operatore poteva falsificare chiamate API autenticate senza mai vedere una password.

Non risultano furti. ACINQ non ha pubblicato alcun avviso di sicurezza né un numero CVE per il problema, e CryptoSlate, che ha riferito la modifica il 17 ottobre, non indica quanti nodi fossero esposti. Per il piccolo gruppo di persone che gestiscono Eclair in proprio, però, la correzione cambia il modo di usare il software, e gli sviluppatori raccomandano di aggiornare.

Cosa cambia in Eclair v0.14.4

Eclair è una delle principali implementazioni open source di Lightning, la rete di pagamento che gira sopra bitcoin. Espone un’API JSON su una porta locale, così che il proprietario possa controllare i saldi, aprire e chiudere canali e inviare o ricevere pagamenti da script o dallo strumento a riga di comando incluso, eclair-cli.

La nuova regola sta in una riga delle note di rilascio:

«L’API ora rifiuta le richieste che contengono un’intestazione Origin, il che significa che non può più essere usata da un browser web.» (note di rilascio di Eclair v0.14.4)

Il lavoro che c’è dietro è la pull request #3380, intitolata «Reject API access from browsers». L’ha scritta lo sviluppatore che firma come pm47, l’ha approvata sstone, ed è stata aperta e unita lo stesso giorno, il 15 settembre 2026. La correzione è quindi rimasta un mese nel ramo principale di Eclair prima di arrivare in una versione con tag. Secondo la PR e il relativo commit, ogni richiesta con un’intestazione Origin riceve ora un errore HTTP 403 prima che il comando richiesto venga eseguito, e gli header CORS che indicavano ai browser quali siti potessero parlare con l’API sono spariti. La modifica tocca sei file, con 111 righe aggiunte e 8 rimosse, e include test per un’origine del browser con e senza credenziali, per le connessioni websocket e per il valore speciale Origin: null. Ogni chiamata rifiutata lascia inoltre un avviso nel registro del nodo. La PR dice di risolvere la segnalazione di Project Loupe e, per costruzione, qualsiasi altra segnalazione CSRF diretta a un singolo endpoint.

Il nuovo controllo rompe anche qualcosa di proposito. L’API non può più essere chiamata da un browser in nessun caso, nemmeno da una pagina servita dallo stesso host. Chi ha costruito una dashboard web che parla direttamente con Eclair deve ora mettere un proprio server back-end tra la pagina e il nodo. Script, curl ed eclair-cli non sono toccati, perché non inviano quell’intestazione.

Come una pagina web poteva raggiungere il tuo nodo Lightning Network

L’attacco descritto nelle note di rilascio è quello che la PR chiama CSRF da browser, sigla di cross-site request forgery. L’idea: il codice di un sito fa eseguire al tuo browser un’azione su un altro servizio, sfruttando un accesso che il browser già possiede. All’attaccante non serve mai la tua password. La fornisce il tuo browser.

L’API di Eclair usa l’autenticazione HTTP basic, il vecchio schema in cui il browser chiede la password una volta sola e poi la ricorda. I browser allegano queste credenziali memorizzate alle richieste successive, comprese quelle lanciate da altri siti. Gli endpoint dell’API accettano inoltre parametri in formato form, perciò basta un normale modulo HTML nascosto in una pagina web per costruire una chiamata valida. Le note aggiungono il dettaglio che conta: la pagina attaccante non può leggere la risposta, ma a quel punto il comando è già stato eseguito.

La catena funziona solo se l’operatore ha, in qualche momento, aperto l’API in quel browser e salvato l’accesso. È il caso di chi ha usato uno strumento basato sul browser o ha provato l’API a mano. CryptoSlate elenca i comandi raggiungibili tramite l’API: leggere lo stato del nodo, aprire e chiudere canali, inviare e ricevere pagamenti. Dato che i pagamenti rientrano nell’elenco, una chiamata falsificata poteva in linea di principio spostare denaro fuori dal nodo, che per sua natura tiene i fondi in un hot wallet. Né ACINQ né CryptoSlate documentano un caso in cui sia successo.

Perché limitarsi al loopback non bastava

Agli operatori dei nodi si dice di tenere l’API sul loopback, l’indirizzo 127.0.0.1 raggiungibile solo dallo stesso computer. Il consiglio resta valido e blocca gli sconosciuti su internet. Non serve però a nulla contro il CSRF, perché il browser che porta la richiesta falsificata gira proprio su quel computer. Dal punto di vista del nodo, la chiamata arriva da un client locale di cui fidarsi.

La PR osserva che controllare soltanto la presenza dell’intestazione, invece di confrontarla con un elenco di siti ammessi, copre anche le richieste inviate con Origin: null e il DNS rebinding. Il rebinding è un trucco con cui una pagina web induce il browser a trattare un servizio sulla tua macchina come parte del sito dell’attaccante. Con la nuova regola il contenuto dell’intestazione non conta: se c’è, la richiesta viene rifiutata.

Nessun CVE, nessuna vittima nota, diverse incognite

La pagina GitHub di ACINQ dedicata agli avvisi di sicurezza indicava il 17 ottobre che non ne risultavano pubblicati. Per questo problema non è stato trovato alcun identificativo CVE. La versione cita le correzioni di rafforzamento della sicurezza, «per lo più originate da @erickcestari e dal progetto Loupe», e la voce sull’Origin rimanda a una scheda del tracker di audit di Project Loupe, project-loupe/audit-eclair#223. È così che la segnalazione è arrivata agli sviluppatori; le fonti non dicono chi l’abbia presentata personalmente, né quando.

Al 17 ottobre restano aperte diverse domande:

1. Quali versioni fossero esposte. Le note di rilascio descrivono un impianto (autenticazione basic più endpoint con parametri in formato form) che sembra precedere la v0.14.4, ma nessuna fonte indica una prima versione interessata.
2. Se l’API sia attiva per impostazione predefinita e con quale politica sulle password. Il progetto raccomanda agli operatori di non renderla raggiungibile dall’esterno, e i documenti non vanno oltre.
3. Quanti nodi eseguano l’API in modo raggiungibile da un browser e se qualcuno abbia provato l’attacco. Non è stato segnalato nulla.
4. Se per la scoperta sia stata pagata una ricompensa (bug bounty).

Gli sviluppatori sono chiari sui limiti della loro stessa correzione. Nella PR #3380 pm47 scrive: «Questa è una difesa contro il CSRF da browser, non un meccanismo di autenticazione.» Un programma che non sia un browser può semplicemente omettere l’intestazione. Lo stesso testo aggiunge che l’API «non dovrebbe comunque mai essere esposta oltre il loopback», concetto che anche CryptoSlate attribuisce a pm47.

Un autunno intenso per le correzioni di sicurezza di Eclair

Il blocco delle richieste dal browser è solo una voce di un elenco più lungo. La stessa versione raccoglie interventi di rafforzamento che, nelle parole di ACINQ, contano perché «alcuni di questi problemi possono essere sfruttati da nodi malevoli». Le voci del changelog, numerate da #3387 a #3401, riguardano la validazione della lunghezza del file del seed, la protezione da un back-end bitcoind malevolo, i controlli sugli script di chiusura inviati dalla controparte di un canale, un controllo di lunghezza sui pacchetti onion e correzioni a splicing e finanziamento dei canali al volo. Per gli operatori sono motivi sufficienti per aggiornare, che abbiano mai toccato l’API da un browser oppure no.

È anche la quarta versione di Eclair dalla fine di luglio. All’inizio del mese CryptoSlate (ripreso da KuCoin News il 2 ottobre) ha descritto un bug di esaurimento della memoria legato ai registri dei canali non finanziati, presente nella v0.14.0 e in quelle precedenti e corretto nella v0.14.1 il 29 luglio. In una prova di laboratorio sulla v0.14.0, un heap di memoria da 4 GB si è esaurito dopo circa 48 minuti e, poiché i registri restavano su disco, un riavvio mandava di nuovo in crash il nodo. Il ricercatore Erick Cestari ha pubblicato i dettagli il 30 settembre, e la v0.14.3 era la versione che agli operatori veniva detto di usare. Lo stesso rapporto citava un secondo bug, LNF-2026-0003, trovato da Matt Morehouse con il suo strumento lnfuzz, che lasciava processi di canale orfani a consumare memoria fino a una disconnessione o a un riavvio.

Lightning ha vissuto spaventi più grossi. Nell’ottobre 2023 lo sviluppatore Antoine Riard rese noto il «replacement cycling», un attacco ai nodi che inoltrano pagamenti e che riguardava tutte le implementazioni, Eclair compresa, come riportò Bitcoin Optech il 25 ottobre 2023. Le implementazioni rilasciarono mitigazioni, come una ritrasmissione più frequente e, in Eclair e LND, la scansione della mempool, anche se lo sviluppatore di LDK Matt Corallo disse che «non ci si aspetta che risolvano questo problema». Optech non segnalò alcun uso dell’attacco in natura. Il problema dell’API di Eclair è più circoscritto: richiede il browser dell’operatore, un accesso salvato e una pagina malevola visitata nel momento sbagliato.

Tre release di sicurezza di Eclair in cinque settimane

Con la v0.14.5, Eclair ha pubblicato in poco più di cinque settimane tre versioni presentate come rafforzamento della sicurezza. La v0.14.3 è arrivata il 14 settembre con correzioni venute soprattutto da Project Loupe, la v0.14.4 il 15 ottobre con correzioni soprattutto di erickcestari e Project Loupe, e la v0.14.5 il 20 ottobre, che cita i due nuovi ricercatori. Le due patch precedenti della serie 0.14, la v0.14.1 del 29 luglio e la v0.14.2 del 26 agosto, compaiono nella pagina delle release del progetto come correzioni di bug.

Tutte e tre le release di sicurezza portano lo stesso consiglio di ACINQ: aggiornare. Per un operatore il costo è un riavvio ogni volta, dato che nessuna richiede di chiudere i canali. La differenza, questa volta, è quanto poco viene detto. Il codice della v0.14.5 è pubblico, ma le note non spiegano cosa sia stato corretto, e ACINQ non ha detto quando lo farà. La release riguarda solo Eclair: LND, Core Lightning e LDK pubblicano le proprie patch con tempi propri.

Cosa devono fare gli operatori prima di riavviare

L’aggiornamento in sé è semplice. ACINQ afferma che la v0.14.5, ora la più recente, è pienamente compatibile con le versioni precedenti, come lo era la v0.14.4, e che non serve chiudere i canali: si ferma Eclair, si installa la nuova versione, si riavvia. Le release sono firmate con la chiave E04E48E72C205463 e le build sono deterministiche, quindi il binario può essere verificato rispetto al sorgente pubblicato.

1. Verifica la firma della release scaricata rispetto alla chiave di firma di ACINQ prima di installarla.
2. Ferma Eclair, sostituisci i binari e riavvia; i canali esistenti e i fondi restano al loro posto.
3. Controlla che l’API resti in ascolto solo su 127.0.0.1 e che la sua password non sia riusata altrove.
4. Se una dashboard nel browser chiamava direttamente l’API, sposta quelle chiamate dietro un piccolo server tuo, perché la via del browser ora restituisce 403.
5. Cancella dal browser l’eventuale accesso basic-auth salvato per l’API, che ormai non serve più.

Gestire un nodo Lightning significa tenere le chiavi online perché il nodo possa firmare pagamenti in qualsiasi momento. È un compromesso, spiegato nella nostra guida su come funzionano i wallet crypto, ed è il motivo per cui un’API locale in grado di spendere merita la stessa cura del seed stesso.

Chi riguarda l’aggiornamento di Eclair

La modifica riguarda chi gestisce Eclair come server e ne usa l’API JSON: operatori di nodi di instradamento e commercianti o sviluppatori che hanno costruito sopra di essa una soluzione propria. Per numero di nodi Eclair è un’implementazione minoritaria, ma il suo sviluppatore pesa sulla rete: ACINQ gestisce uno dei più grandi nodi di instradamento e produce il wallet mobile Phoenix.

Il problema riguarda l’API dell’operatore, non le app di wallet per smartphone. ACINQ non ha pubblicato una dichiarazione su Phoenix, e nulla nelle note di rilascio dice che i suoi utenti debbano intervenire. Chi paga su Lightning tramite un’app custodial o un’altra implementazione non ha niente da fare. Chi si avvicina per la prima volta alle reti di secondo livello può partire dalla nostra voce di glossario sul layer 2.

Cosa aspetta chi gestisce nodi Eclair

Non è stata fissata alcuna data per altri interventi. La scheda audit-eclair#223 potrebbe portare a un resoconto più completo di Project Loupe a divulgazione conclusa; non è stato indicato alcun calendario. ACINQ non ha detto quando descriverà le falle corrette nella v0.14.5. La versione da installare è ora la v0.14.5, su GitHub dal 20 ottobre, che sostituisce la v0.14.4 come versione raccomandata da ACINQ.