Aggiornato al 3 novembre 2026.
BTCPay Server ha identificato le versioni 2.4.1 e precedenti come bersaglio dei furti da hot wallet segnalati il 1° novembre. Nell’avviso pubblicato il 2 novembre il progetto raccomanda agli operatori di quelle installazioni una nuova macchina e un nuovo wallet, anche se nel frattempo hanno aggiornato il software.
È il punto da non perdere: chiudere una vulnerabilità non revoca automaticamente l’accesso che un attaccante potrebbe avere già ottenuto. Un saldo apparentemente invariato non esclude una compromissione precedente. La risposta dipende quindi dalla versione eseguita al momento dell’allerta, non soltanto da quella mostrata oggi.
BTCPay Server: quali installazioni sono coinvolte
L’avviso ufficiale del 2 novembre riguarda server 2.4.1, versione del 23 luglio, o precedenti. Secondo il team, gli attaccanti hanno usato un metodo diverso per sfruttare una vulnerabilità già corretta nella 2.4.2, pubblicata il 7 agosto. Non viene descritta come una falla nel protocollo Bitcoin.
Per i server che eseguivano già la 2.4.2 o una versione successiva quando è stata diramata l’allerta del 1° novembre, il progetto riferisce di non avere osservato impatti da questi attacchi. È una conclusione circoscritta all’indagine, non una garanzia di sicurezza assoluta contro qualsiasi problema futuro.
| Situazione | Indicazione del progetto |
|---|---|
| 2.4.2 o successiva già prima dell’allerta | Nessun impatto osservato da questi attacchi |
| 2.4.1 o precedente | Nuovo server e nuovo wallet, anche senza furti visibili |
| Aggiornamento dalla vecchia versione dopo l’allerta | La raccomandazione di ricostruzione resta valida |
| Furto o accesso non autorizzato | Considerare compromessi macchina e segreti accessibili |
Perché aggiornare non equivale a bonificare
Un aggiornamento corregge il codice distribuito dal progetto. Non dimostra però che una password sottratta sia diventata inutilizzabile, che una sessione abusiva sia cessata o che ogni componente della vecchia macchina sia affidabile. Confondere prevenzione e recupero può lasciare attivo un percorso d’accesso già acquisito.
Per questo la raccomandazione non è ripristinare una copia integrale del vecchio server su una nuova macchina. Il team chiede un ambiente nuovo con software supportato e credenziali sostituite. Non si tratta di cancellare indiscriminatamente tutto: log rilevanti e registrazioni delle transazioni vanno preservati prima della sostituzione per l’indagine.
Hot wallet e chiavi conservate fuori dal server
Un hot wallet conserva sul server le chiavi necessarie a spendere. Nel caso descritto, l’accesso alla macchina può quindi avere conseguenze dirette sui fondi. La nostra guida ai wallet custodial e non custodial aiuta a distinguere controllo delle chiavi, connessione e responsabilità operativa.
Il progetto precisa che questi furti non hanno interessato i fondi di wallet le cui chiavi di spesa erano esterne al server, inclusi gli hardware wallet. Non ne deriva che una vecchia installazione sia affidabile se usa un dispositivo esterno: la raccomandazione di ricostruire il server rimane anche in quel caso.
Un nuovo wallet richiede un nuovo segreto
La sequenza ufficiale parte dalla creazione di un wallet su un dispositivo fidato, con una nuova seed, e dal trasferimento dei fondi residui dell’hot wallet. Riutilizzare la vecchia seed sulla nuova macchina mantiene a rischio quei fondi se il segreto era stato esposto. Nuovo indirizzo e nuovo segreto non sono automaticamente la stessa cosa.
La nostra spiegazione della seed phrase e della sua protezione chiarisce questa differenza. Non bisogna incollare il vecchio segreto in un sito che promette recuperi, né inviarlo al supporto. L’avviso chiede espressamente di non condividere seed, chiavi private, password o altre credenziali.
Dopo aver protetto quanto rimane e conservato le evidenze, il progetto indica di mettere offline il vecchio server e preparare una macchina virtuale pulita. Le credenziali potenzialmente esposte devono essere revocate e sostituite da un dispositivo fidato. Inserire le nuove credenziali sulla macchina sospetta ne vanificherebbe la separazione.
La release 2.4.7 non riscrive la cronologia
Preservare una copia per l’indagine è diverso dal rimetterla in produzione. Prima di sostituire l’ambiente occorre mantenere i materiali di recupero necessari e verificare di non perdere l’unica copia disponibile. Questo non rende sicuro riutilizzare credenziali o seed che potrebbero essere già note all’attaccante.
Le note ufficiali della 2.4.7, pubblicata il 29 ottobre, riportano ulteriori correzioni di sicurezza, affidabilità e contabilizzazione dei pagamenti. Sono un riferimento per l’aggiornamento, ma la loro presenza non dimostra che una macchina rimasta vulnerabile fino a novembre non sia stata violata prima.
Il rilascio e la risposta all’incidente rispondono a domande diverse: quale codice installare e come trattare un ambiente già sospetto. Per un’installazione gestita da terzi, il progetto invita a contattare il provider per la migrazione a una nuova VM. Qui non abbiamo eseguito aggiornamenti, trasferimenti o test sulle installazioni dei lettori.
Perdite e indagine: cosa non si può dedurre dagli indirizzi
BTCPay Server pubblica indirizzi di destinazione segnalati negli incidenti, ma avverte che alcune attività potrebbero precedere i furti conosciuti. Saldi e cronologia di quegli indirizzi non sono quindi un totale confermato delle perdite. Non attribuiamo automaticamente ogni transazione a questo attacco e non promettiamo recuperi.
Per una segnalazione servono versione precedente, tempi con fuso orario e riferimenti pubblici delle transazioni; dai log vanno rimossi i segreti. Se sono stati sottratti fondi, il progetto raccomanda anche la denuncia alle autorità locali. Il messaggio operativo resta preciso: identificare l’esposizione storica e ricostruire la fiducia nell’ambiente, non limitarsi a leggere un numero di versione aggiornato.
