BTCPay Server: se hai un hot wallet, spegni il server (possono rubarti tutto)! (aggiornato: 2 novembre 2026, ore 08:30)

Nessun numero ufficiale sulle perdite, nessuna patch, nessuna spiegazione tecnica. Solo un'istruzione secca: spegnere subito il server. Nella serata del primo novembre 2026 il team di BTCPay Server, il processore di pagamenti open source che permette ai commercianti di accettare Bitcoin senza intermediari, ha lanciato un allarme di sicurezza: alcuni aggressori stanno svuotando gli hot wallet ospitati sulle istanze del software. Chi tiene fondi in un wallet gestito da un server colpito rischia di vederli sparire in un'unica transazione. Ed è la conseguenza diretta di un modello che mette custodia e sicurezza interamente sulle spalle di chi installa il software.

L'allarme: «spegnetelo fino alla fine dell'indagine»

L'avviso è arrivato dall'account ufficiale del progetto su X. «Stiamo ricevendo segnalazioni di hot wallet su istanze BTCPay Server svuotati da aggressori non autorizzati. Se gestisci un'istanza, spegnila (./btcpay-down.sh) fino al completamento dell'indagine», si legge nel messaggio.

L'indicazione non si limita a versioni specifiche e nessuna comunicazione successiva ha dichiarato sicuro il riavvio. Alcuni provider di hosting, tra cui LunaNode, hanno spento per precauzione una parte delle installazioni gestite.

Accesso da amministratore, ma non si sa come

Il fondatore Nicolas Dorier ha spiegato che gli aggressori hanno ottenuto l'accesso come amministratori sulle istanze colpite. Il punto cruciale, però, è ancora oscuro: non è stato stabilito se abbiano usato credenziali rubate, una falla del software o un'altra strada. Il progetto non ha ancora spiegato pubblicamente la debolezza tecnica dietro le intrusioni.

Sulle versioni coinvolte le fonti non coincidono del tutto. Secondo la maggior parte dei resoconti, i risultati preliminari di Dorier collegano le segnalazioni alle versioni precedenti alla 2.4.2. Un'altra ricostruzione parla invece di un avviso successivo del progetto, che avrebbe individuato un vettore d'attacco nelle installazioni con la versione 2.4.1 o precedenti, rilasciata il 23 luglio 2026. Di fatto la soglia è la stessa, ma cambia il peso dell'informazione: valutazione preliminare del fondatore in un caso, esito dell'indagine nell'altro. L'allarme originale non nominava alcuna versione.

Il caso della 2.4.7, la release corrente, è ancora più delicato. Dorier ha indicato che i server pubblici del progetto, aggiornati a questa versione, non sono stati attaccati. Una fonte riferisce che non esistono segnalazioni credibili di wallet svuotati con la 2.4.7. Altre sottolineano però che il fondatore si è fermato prima di confermare che le versioni recenti siano al sicuro. Il fatto che i server del progetto siano intatti, insomma, non dimostra che lo siano tutte le installazioni aggiornate.

Non risultano dati sulla quantità di bitcoin sottratti, sul numero di server compromessi o su quello degli utenti colpiti.

Un autunno complicato per BTCPay Server

L'incidente arriva in un periodo già movimentato. La 2.4.7, rilasciata il 29 ottobre, cioè appena tre giorni prima dell'allarme, ha corretto 85 problemi di sicurezza segnalati tramite il programma OSS Scanner di Anthropic: 1 critico, 13 di gravità alta, 52 media e 19 bassa, relativi a permessi, autenticazione, gestione dei pagamenti e altre funzioni. Al momento non c'è alcun collegamento confermato tra quelle correzioni e gli svuotamenti in corso.

Ad agosto 2026, inoltre, la versione 2.4.2 aveva chiuso una vulnerabilità che consentiva ad aggressori non autenticati di ottenere i macaroon di LND (Lightning Network Daemon), i token di autorizzazione del nodo Lightning. Quella falla era già sfruttata attivamente per svuotare i wallet dei nodi Lightning e allora BTCPay aveva precisato che gli hot wallet on-chain non erano coinvolti. Stavolta, invece, sono proprio quelli a finire nel mirino. Se i due episodi condividano lo stesso vettore d'attacco non è confermato.

Il prezzo dell'autocustodia

Per capire perché l'attacco faccia così male bisogna guardare a come funziona un hot wallet. In questa configurazione il seed è memorizzato sul server, collegato a Internet, che firma le transazioni in automatico. La documentazione di BTCPay lo dice senza giri di parole: la funzione è contrassegnata come «PERICOLO» e «comporta implicazioni di sicurezza». Chi entra nel server può inviare le monete al proprio indirizzo, e uno "sweep" le porta via tutte in un colpo.

C'è poi il rovescio della medaglia del self-hosting. Ogni commerciante gestisce il proprio server, quindi non esiste un interruttore centrale da abbassare: l'unica arma del progetto era chiedere a ogni singolo operatore di spegnere la propria istanza. La stessa indipendenza dagli intermediari che rende BTCPay Server attraente diventa, in un'emergenza, una responsabilità individuale piena.

Cosa fare adesso

Se gestisci un'istanza con un hot wallet, la prima mossa è spegnerla con ./btcpay-down.sh e lasciarla offline finché il team non avrà concluso l'indagine. Aggiornare alla 2.4.7 è sensato, ma non è un lasciapassare: nessuno ha confermato che basti.

Chi usa una configurazione watch-only, con il seed su un dispositivo di firma esterno che non tocca mai il server, non risulta esposto a questo incidente: BTCPay Server può infatti ricevere pagamenti anche senza conoscere il seed. Chi invece ha subito perdite deve inviare al progetto i dettagli dell'incidente e i log del server, l'unico materiale da cui l'indagine può ricostruire la strada seguita dagli aggressori. Una correzione, per ora, non è stata annunciata.

Fonti: coindesk.com, news.bitcoin.com, cryptika.com