BTCPay Server, 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 software gratuito e self-hosted per accettare pagamenti in bitcoin, ha chiesto domenica 1° novembre a chiunque gestisca un’istanza di spegnerla con il comando ./btcpay-down.sh, dopo le segnalazioni di aggressori che svuotavano gli hot wallet sui server dei commercianti. Lunedì il progetto ha detto di aver individuato un vettore d’attacco rivolto alla versione 2.4.1 e a quelle precedenti e ha invitato gli operatori ad aggiornare alla 2.4.7, ha riferito Cointelegraph. Nessuno ha pubblicato una cifra delle perdite, il numero dei server colpiti o una spiegazione di come gli aggressori siano entrati.
Cosa ha chiesto BTCPay agli operatori
- Spegnere il server. BTCPay lo ha scritto su X intorno alle 22:25 UTC di domenica, ha riferito Bitcoin.com News: «Se gestite un’istanza, spegnetela (./btcpay-down.sh) finché non avremo concluso l’indagine». La richiesta non indicava alcuna versione, quindi valeva per tutti gli operatori.
- Aggiornare alla 2.4.7, l’ultima versione disponibile al momento in cui scriviamo. Questa seconda richiesta è arrivata lunedì, secondo Cointelegraph, in un post di BTCPay sul vettore d’attacco.
- Segnalare ogni furto. Cointelegraph scrive che gli utenti colpiti sono stati invitati a inviare informazioni e log al team di sicurezza del progetto, all’indirizzo [email protected] secondo TokenPost.
BTCPay non ha spiegato come le due richieste si conciliino. Cointelegraph riporta prima l’avviso di spegnimento e poi l’invito ad aggiornare, senza dire che una cosa abbia sostituito l’altra, e sul blog di BTCPay o sulle sue pagine GitHub non abbiamo trovato alcun via libera. Il nodo sta nell’aggiornamento stesso: lo script di aggiornamento delle installazioni Docker, btcpay-update.sh, si chiude riavviando lo stack. Un server spento e aggiornato in questo modo è quindi di nuovo in funzione prima che il progetto abbia dichiarato conclusa l’indagine. In tutto ciò che abbiamo potuto leggere, BTCPay non ha detto quando un server spento possa tornare online, né se l’aggiornamento debba attendere quel momento.
Un server spento, poi, non incassa pagamenti, perché btcpay-down.sh ferma e rimuove i container dello stack. Per un negozio la scelta ha dunque un costo in vendite da una parte e il contenuto di un hot wallet dall’altra. Il comando riguarda l’installazione con Docker. Chi usa altre configurazioni era coinvolto dalla stessa richiesta, ma deve fermare il servizio a modo suo.
Cosa ha detto il fondatore sull’attacco agli hot wallet di BTCPay
Circa due ore dopo l’allarme, il fondatore Nicolas Dorier ha pubblicato i primi dettagli. Le segnalazioni «sembrano riguardare versioni di BTCPay Server precedenti alla 2.4.2», ha scritto, secondo CoinDesk, mentre i server pubblici del progetto, aggiornati alla 2.4.7, «non sono stati attaccati». Ha aggiunto che l’aggressore aveva effettuato l’accesso come amministratore sui server colpiti e che il team non sapeva ancora come avesse ottenuto quell’accesso.
I lettori incontreranno due formule per le versioni. «Precedenti alla 2.4.2» e «2.4.1 o precedenti» indicano le stesse release, quindi la differenza è solo di linguaggio. Il passaggio che conta davvero è quello dal «sembrano riguardare» di Dorier al vettore d’attacco dichiarato lunedì, anche se di quest’ultimo non è stata pubblicata alcuna descrizione tecnica.
Nessuna delle due dichiarazioni copre la parte centrale dell’intervallo. «Non risultano segnalazioni credibili di svuotamenti di hot wallet per chi usa l’ultima versione, la 2.4.7», ha scritto BTCPay. Niente di quanto abbiamo letto dice lo stesso per le versioni dalla 2.4.2 alla 2.4.6, e CoinDesk ha osservato che Dorier non ha affermato che le versioni più recenti siano sicure.
È stata nominata una sola azienda. Bitcoin.com News scrive che realtà come Coincards hanno messo offline le proprie installazioni dopo l’avviso. La testata non riporta perdite né da Coincards né da altri commercianti.
Perché un accesso da amministratore può svuotare un hot wallet
BTCPay non custodisce il denaro di nessuno. La sua documentazione lo definisce «uno stack software open source e self-hosted, non un’azienda»: ogni commerciante lo installa su una macchina che controlla e riceve i fondi direttamente nel proprio wallet. È l’autocustodia applicata alla cassa di un negozio, e spiega la forma insolita di questo allarme. Non c’è un interruttore centrale, come ha fatto notare CoinDesk, perciò BTCPay poteva soltanto chiedere a ogni titolare di agire. Nessuna società possiede nemmeno un elenco clienti a cui scrivere, quindi un commerciante che non segue gli account del progetto potrebbe non aver saputo nulla.
Il software può funzionare con due tipi di wallet del negozio. In uno il server conosce soltanto le chiavi pubbliche e controlla i pagamenti in arrivo, mentre le chiavi private stanno altrove, per esempio su un hardware wallet. Nell’altro, un hot wallet, la seed phrase è conservata sul server perché i pagamenti possano essere firmati in automatico. La documentazione dei wallet di BTCPay inserisce questa funzione sotto un’etichetta DANGER: «L’uso della funzione hot wallet comporta implicazioni di sicurezza».
La firma automatica è la comodità ed è anche l’esposizione. Chi controlla il server può spendere ciò che controlla la seed, con un unico prelievo che porta le monete fuori dal wallet. Nessuna delle fonti principali dice che i commercianti senza hot wallet siano colpiti, e BTCPay non ha detto che siano al sicuro. Il suo allarme non faceva alcuna distinzione, anche se il core contributor Uncle Rockstar Developer l’ha messa così, secondo Bitcoin.com News: «Non è un’esercitazione: spegnete il vostro BTCPay Server se avete un hot wallet».
Perché la 2.4.7 non viene presentata come una correzione
BTCPay non ha annunciato alcuna patch per questi furti. La versione 2.4.7 è uscita il 29 ottobre alle 13:48 UTC, poco più di tre giorni prima dell’allarme, quindi non è stata scritta in risposta a esso. È la release per cui il progetto non ha segnalazioni credibili di svuotamenti, il che è un’affermazione diversa dal dire che la falla sia chiusa. Le note di rilascio su GitHub non collegano alcuna modifica alle segnalazioni di novembre, e lo stesso vale per le versioni precedenti. Ecco cosa dicono le note, release per release:
| Versione | Data (2026) | Cosa dicono le note di rilascio |
|---|---|---|
| 2.4.1 | 23 luglio | Versione con novità e correzioni; il vettore d’attacco indicato da BTCPay riguarda questa versione e le precedenti |
| 2.4.2 | 7 agosto | Corregge la falla critica «sfruttata attivamente» ad agosto |
| 2.4.3 | 24 agosto | Versione di sicurezza, raccomandata per i server condivisi da molti utenti |
| 2.4.4 | 7 settembre | Aggiornamento di sicurezza, secondo il blog di BTCPay |
| 2.4.5 | 6 ottobre | Blocca per impostazione predefinita le destinazioni su reti private nelle richieste in uscita |
| 2.4.6 | 26 ottobre | Ampio rafforzamento della sicurezza |
| 2.4.7 | 29 ottobre | Corrette 85 vulnerabilità: 1 critica, 13 alte, 52 medie, 19 basse |
Le 85 vulnerabilità corrette nella 2.4.7 sono emerse dal programma OSS Scanner di Anthropic, e le note definiscono l’aggiornamento «vivamente raccomandato», soprattutto per i server condivisi da più commercianti.
Una nuova versione, poi, non raggiunge nessuno da sola. «Pubblicare le correzioni non aggiorna automaticamente i server gestiti in modo indipendente», ha scritto Bitcoin.com News, e la documentazione di BTCPay descrive le notifiche di una nuova release, seguite da un aggiornamento che l’amministratore avvia dalla pagina Maintenance o da una shell come root. Un server rimasto a una build di luglio non ha ricevuto nessuna delle release elencate, a meno che qualcuno non le abbia installate.
La falla di agosto colpì i nodi Lightning, e allora BTCPay scagionò gli hot wallet
È la seconda emergenza di BTCPay in meno di tre mesi. Il 7 agosto il suo avviso di sicurezza spiegava che tutte le versioni precedenti alla 2.4.2 permettevano a un aggressore remoto non autenticato di ottenere i file di credenziali .macaroon di LND e di prendere il controllo del nodo Lightning di un commerciante. Dei fondi furono rubati. Tra le vittime citate c’erano Foundation, il produttore di hardware wallet, e Citadel21, secondo CoinDesk, che aggiungeva come l’hot wallet on-chain di Foundation fosse rimasto intatto. BTCPay non ha dato un totale né nell’avviso né nel post di aggiornamento del 10 agosto.
Le istruzioni somigliavano molto a quelle di domenica: aggiornare alla 2.4.2 e, per chi usava LND e non poteva farlo subito, mettere il server offline. L’avviso, aggiornato per l’ultima volta il 30 ottobre, dice ancora: «I wallet on-chain di BTCPay Server, hot wallet compresi, non sono interessati». L’avviso registra anche una precauzione di quella settimana che BTCPay ritirò dopo aver confermato che era colpito soltanto LND. Quell’episodio di agosto non dice nulla su cosa debbano fare gli operatori adesso.
Quella frase descrive soltanto la falla di agosto. Le nuove segnalazioni riguardano gli hot wallet, e le versioni in questione sono le stesse da cui agosto aveva invitato gli operatori ad allontanarsi. Se i due attacchi siano collegati non si sa. Cointelegraph lo dice in modo esplicito, e BTCPay non l’ha affrontato in nulla di ciò che abbiamo potuto leggere.
BTCPay non ha detto agli operatori di spostare i fondi
Molti operatori vorranno fare di più che spegnere il server, quindi lo stato di questi passi va chiarito. Nelle cronache che abbiamo letto e sulle pagine del progetto, BTCPay non ha detto agli operatori di spostare le monete dai wallet custoditi sul server per questo incidente, né di cambiare password o chiavi API. I consigli di questo tipo che si trovano altrove non sono di BTCPay.
Due osservazioni più vecchie possono essere scambiate per un’istruzione. Il post di BTCPay del 10 agosto indica la cold storage come buona pratica generale, ma precede queste segnalazioni e non le riguarda. Bitcoin.com News scrive che Dorier ha ribadito l’importanza di limitare i saldi degli hot wallet a ciò che gli operatori possono permettersi di perdere, senza presentarlo come un’istruzione per questo incidente. La nostra guida ai tipi di wallet e alla custodia spiega il compromesso a chi vuole valutarlo. Nulla di quanto scritto qui è una raccomandazione di spostare o detenere alcun asset.
Cosa nessuno ha ancora detto
- Quanto è stato sottratto. Non è stato pubblicato alcun totale, né in bitcoin né in dollari.
- Quanti commercianti o server sono stati colpiti.
- Come l’aggressore abbia ottenuto l’accesso da amministratore e quale sia il vettore d’attacco.
- Se gli operatori debbano aggiornare subito o restare offline, e quando un server spento possa tornare in funzione.
- Se le release dalla 2.4.2 alla 2.4.6 siano esposte, e se la 2.4.7 chiuda la strada o semplicemente non sia stata attaccata.
- Se i furti siano legati alla falla di agosto.
- Chi ci sia dietro. Non sono stati pubblicati nemmeno indirizzi on-chain o ID di transazione.
Per ora la documentazione è scarsa. Quando abbiamo controllato, intorno alle 05:50 UTC di lunedì, il blog di BTCPay non aveva alcun post sull’incidente (l’ultimo è datato 5 ottobre), la pagina degli avvisi di sicurezza su GitHub era vuota, nessun numero CVE compariva in ciò che abbiamo letto e la 2.4.7 era ancora la release più recente. Cointelegraph ha scritto che BTCPay non aveva risposto alla richiesta di commento prima della pubblicazione.
CoinDesk ha collocato l’allarme nella stessa settimana dell’attacco hacker a Binance, ma nessuna fonte collega i due fatti.
I prossimi documenti da seguire sono un post sul blog di BTCPay o un avviso su GitHub che indichi la causa all’origine, una release 2.4.8 e qualsiasi dichiarazione secondo cui i server spenti possano tornare online. Non abbiamo trovato nulla che ritiri la richiesta di domenica di restare offline.