Domenica 8 novembre 2026, poco prima delle 14 UTC, il progetto LNbits ha diramato l’avviso che nessun operatore Lightning vuole mai leggere: spegnete i vostri server, subito. Non era un’esercitazione. Mentre il messaggio circolava su Nostr e su X, alcuni aggressori stavano gi\u00e0 creando account non autorizzati su istanze self-hosted e portavano via i fondi, satoshi dopo satoshi.<\/p>
Per tutto il 2026 la Lightning Network aveva vissuto una lunga stagione di allarmi senza vittime: una patch dopo l’altra su Core Lightning, LDK ed Eclair, falle divulgate in modo responsabile, nessuna perdita confermata. L’edizione inglese di questa testata, ancora il 22 ottobre, poteva scrivere che non risultavano furti. Tre settimane dopo quella frase non regge pi\u00f9: il caso LNbits \u00e8 il primo prelievo illecito documentato dell’intero ciclo, e cambia il registro della conversazione.<\/p>
La parte scomoda \u00e8 dove si \u00e8 rotto il meccanismo. Non nei canali di pagamento, non negli HTLC, non nel routing onion: il protocollo ha tenuto. A cedere \u00e8 stato lo strato che quasi nessuno guarda, quello delle applicazioni e della custodia costruite sopra Bitcoin. Questo pezzo ricostruisce cosa \u00e8 successo, perch\u00e9 conta pi\u00f9 del solito, e cosa dovrebbe fare adesso chi gestisce un nodo o un’istanza in Italia.<\/p>
La cronologia \u00e8 stretta e nervosa. Intorno alle 12:33 UTT dell’8 novembre, i manutentori di LNbits segnalano un problema sull’estensione Paywall; poco dopo, alle 13:56, la comunicazione si allarga a un ordine secco rivolto a tutti: \u00abfermate immediatamente i vostri server LNbits\u00bb, perch\u00e9 \u00e8 in corso \u00abun’ondata di attacchi\u00bb che richiede patch di sicurezza. Il servizio ospitato ufficiale, my.lnbits.com, viene sospeso. LNbits \u00e8 uno dei mattoni pi\u00f9 diffusi dell’ecosistema: un software open source che trasforma un singolo nodo Lightning in decine di portafogli, con estensioni per punti vendita, paywall, carte Bolt e bot per le mance. Spegnerlo di colpo significa congelare un pezzo non banale dell’infrastruttura applicativa della rete.<\/p>
Il danno, almeno quello documentato, ha un nome e una cifra. L’operatore olandese Kevin Ravensberg, che gestisce il servizio di mance Bittipbot, ha confermato il prelievo di 2.285.545 satoshi (circa 0,0229 BTC, poco meno di 1.500 euro ai prezzi attuali) dalla propria istanza tra le 09:22 e le 14:00 UTC, in circa cinque ore, come riportato da Bitcoin.com<\/a>. Un secondo utente ha descritto un attaccante che ha creato un nuovo account attraverso la sua istanza e ha sottratto circa 0,023 BTC. Non \u00e8 una fortuna in termini assoluti; \u00e8 per\u00f2 la prova concreta, su catena, che la minaccia \u00e8 uscita dal piano teorico.<\/p> Ben Arc, il creatore di LNbits, ha stimato l’arrivo delle correzioni \u00abentro 24-48 ore\u00bb e ha poi riconosciuto pubblicamente che utenti e sviluppatori avevano subito perdite finanziarie durante l’incidente. La patch \u00e8 arrivata il 10 novembre con la versione 1.7.0, descritta come aggiornamento di sicurezza urgente: tutte le versioni precedenti risultano esposte, e secondo la ricostruzione di TFTC<\/a> il meccanismo esatto dell’exploit non \u00e8 stato ancora divulgato per intero. Ravensberg ha promesso di rimborsare di tasca propria gli utenti colpiti, mentre i fondi restavano bloccati in attesa delle correzioni. Alla pubblicazione della 1.7.0 il progetto non aveva ancora diffuso un totale aggregato delle somme sottratte tra tutte le istanze.<\/p> Per capire perch\u00e9 un furto da poche migliaia di euro merita un’analisi, bisogna guardare la curva dell’intero anno. La primavera e l’estate del 2026 avevano portato un’ondata di divulgazioni responsabili: molte segnalazioni, alcune generate in automatico e di scarsa qualit\u00e0, altre reali, tutte chiuse con aggiornamenti prima che qualcuno potesse abusarne. Era il mondo del \u00abpotrebbe succedere\u00bb, fatto di timelock, di cap sui 483 HTLC pendenti per direzione e di modelli formali su carta.<\/p> In autunno il tono \u00e8 cambiato. Core Lightning ha rilasciato la 26.06.8 il 22 settembre e, il 2 ottobre, un avviso esplicito: nodi non aggiornati erano sotto attacco attivo, aggiornare subito; i test furono trattenuti per rallentare il reverse engineering. \u00c8 seguita la 26.06.9 il 7 ottobre. Quasi in parallelo, LDK ha corretto il cosiddetto bug della \u00abbugia alla riconnessione\u00bb: un peer conferma un aggiornamento di stato del canale, poi si riconnette fingendo di non averlo mai ricevuto, inducendo un nodo non aggiornato a firmare una transazione di commitment in conflitto sullo stesso indice. Eclair, dal canto suo, ha pubblicato la 0.14.5 il 20 ottobre con \u00abrafforzamenti\u00bb contro nodi malevoli. In nessuno di questi casi risultarono fondi persi.<\/p> Novembre ha chiuso il cerchio. Prima Electrum, con la 4.8.4 del 6 novembre, poi la cascata su LNbits. Nel mezzo, il bollettino settimanale di freedom.tech<\/a> segnalava la CVE-2026-98432 risolta in Lightning Terminal 0.17.10 (che aggiorna lnd a 0.21.6-beta insieme a loop, pool, faraday e taproot-assets) e la Eclair 0.14.6, con un nuovo parametro che controlla se gli splice possano spendere input non confermati. Dodici mesi di manutenzione intensa, chiusi dal primo furto vero. La differenza non \u00e8 semantica: un bug divulgato \u00e8 un rischio; un prelievo illecito \u00e8 una perdita.<\/p> Il modo pi\u00f9 onesto di leggere l’incidente LNbits \u00e8 quello proposto da TFTC: una catena di custodia a tre anelli che quasi nessun utente aveva mai mappato. Chi lasciava una mancia tramite Bittipbot si fidava di Bittipbot; Bittipbot girava su un’istanza LNbits gestita da Ravensberg; quell’istanza dipendeva dal software LNbits scritto e mantenuto da altri. Tre livelli di fiducia impilati, presentati all’utente come un’unica esperienza \u00abBitcoin\u00bb. Quando l’anello pi\u00f9 in alto, il codice applicativo, ha ceduto, l’intera catena \u00e8 venuta gi\u00f9, e il bitcoiner che credeva di essere sovrano si \u00e8 scoperto creditore non garantito di una serie di intermediari.<\/p> Questo fenomeno ha un nome tecnico ormai ricorrente: la deriva custodiale. La documentazione stessa di LNbits<\/a> \u00e8 chiara: un’istanza ospitata \u00e8 custodiale, perch\u00e9 \u00e8 il fornitore a controllare la fonte di finanziamento; una configurazione self-hosted pu\u00f2 offrire auto-custodia, ma solo se chi la amministra capisce ogni dipendenza. Il problema \u00e8 che molti utenti partono dal presupposto dell’auto-custodia e poi, senza accorgersene, spostano valore reale su strati custodiali, prendendo una decisione di fiducia che non sanno di aver preso. La Lightning Network, nata per spingere i pagamenti Bitcoin fuori dagli exchange, finisce cos\u00ec per ricreare al proprio interno piccole banche invisibili.<\/p> Non \u00e8 un dettaglio da puristi. \u00c8 esattamente il punto in cui un furto da poche migliaia di euro diventa un caso di studio: non misura la fragilit\u00e0 di Bitcoin, ma la distanza tra la promessa dell’auto-custodia e la realt\u00e0 operativa di chi, per comodit\u00e0, delega. Lo stesso ragionamento vale per gli exchange centralizzati e per i custodi istituzionali, con la differenza che quelli, almeno in Europa, oggi hanno un quadro regolatorio sopra la testa; una piccola istanza self-hosted, no.<\/p> Messe in fila, le correzioni degli ultimi due mesi raccontano meglio di qualsiasi commento quanto lavoro di manutenzione ci sia sotto la superficie di una rete apparentemente stabile. La tabella che segue riassume la sequenza, distinguendo tra hardening preventivo e falle con un impatto economico concreto.<\/p>Dal bug al furto: come \u00e8 cambiata l’estate della sicurezza<\/h2>
La catena di custodia a tre anelli<\/h2>
La cronologia della patch wave: da settembre a novembre<\/h2>