BTCPay Server chiede di spegnere le istanze dopo segnalazioni di hot wallet svuotati

BTCPay Server, il software open source con cui molti commercianti accettano pagamenti in bitcoin senza intermediari, ha chiesto la sera del 1° novembre 2026 a chi gestisce un'istanza di spegnerla, dopo segnalazioni di hot wallet svuotati da attaccanti non autorizzati. Nelle ore successive il progetto ha ristretto il perimetro: il vettore d'attacco individuato riguarderebbe le versioni 2.4.1 e precedenti, mentre sulla più recente 2.4.7 non risultano segnalazioni credibili. Nello stesso periodo il prezzo è rimasto pressoché invariato: secondo CoinGecko alle 12:46 UTC del 2 novembre Bitcoin valeva 77.772 dollari, con una variazione di -0,06% in 24 ore.

Che cosa è successo

L'allarme è partito alle 22:25 UTC di domenica 1° novembre con un post dell'account ufficiale di BTCPay Server, che si apre così: «We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers». Il messaggio invitava chiunque gestisse un'istanza a fermarla con lo script btcpay-down.sh e a lasciarla spenta fino alla conclusione dell'indagine. In quel momento la richiesta non era limitata a specifiche versioni.

Circa due ore dopo è intervenuto il fondatore Nicolas Dorier. Nel suo aggiornamento su X ha scritto: «Update on my part: Our public servers were not attacked (on 2.4.7), it seems reports are on before 2.4.2.» Ha aggiunto che sulle istanze colpite l'attaccante è entrato con un accesso da amministratore e che il team stava ancora cercando di capire come lo abbia ottenuto.

Alle 04:07 UTC del 2 novembre è arrivato il terzo passaggio. Nel nuovo comunicato del progetto BTCPay Server afferma che l'indagine ha individuato un vettore d'attacco rivolto alla versione 2.4.1, pubblicata il 23 luglio 2026, e a quelle precedenti, e scrive: «We have no credible reports of hot wallet drains for users running the latest 2.4.7 release.» Il progetto chiede a chi è stato colpito di inviare dettagli e log al proprio indirizzo di sicurezza e raccomanda di mantenere aggiornate le installazioni. In un post collegato segnala che alcune istanze ospitate da provider di hosting, tra cui LunaNode, potrebbero essere state spente automaticamente per proteggere le versioni più vecchie.

Restano punti aperti. Secondo CoinDesk il progetto non ha comunicato l'ammontare delle perdite né il numero di server coinvolti, e non ha annunciato una correzione specifica. Decrypt osserva che non è stato chiarito se gli attacchi abbiano sfruttato falle corrette nell'ultima release. Alla mattina del 2 novembre la pagina degli advisory di sicurezza su GitHub non riportava avvisi pubblicati e il blog ufficiale non conteneva un resoconto dell'episodio. C'è infine una differenza da tenere presente: Dorier parlava di versioni anteriori alla 2.4.2, il comunicato successivo indica la 2.4.1 e precedenti, formulazioni che in pratica coincidono perché la 2.4.2 è la release immediatamente successiva.

Come funziona: i concetti chiave

BTCPay Server è un processore di pagamento self-hosted: il commerciante lo installa su un proprio server, o lo affida a un provider di hosting, e riceve i bitcoin direttamente sui propri indirizzi. Non esiste un operatore centrale in grado di spegnere tutte le istanze: per questo l'appello è rivolto ai singoli gestori, che devono intervenire uno per uno.

Il punto delicato è la distinzione tra portafoglio "freddo" e hot wallet. Nella configurazione più prudente il server conosce solo la chiave pubblica estesa e genera indirizzi di incasso, ma non può spendere. Con l'hot wallet, invece, la documentazione ufficiale spiega che il server usa automaticamente il seed conservato al suo interno per firmare le transazioni, una funzione presente dalla versione 1.2.0. È comodo, per esempio per rimborsi e pagamenti in uscita automatici, ma la stessa documentazione avverte con un riquadro di pericolo: «Using the hot wallet feature comes with security implications».

Ne deriva una conseguenza diretta. Se qualcuno ottiene i privilegi di amministratore su un'istanza con hot wallet, può in linea di principio ordinare al server di firmare un trasferimento verso un indirizzo di sua scelta. Sulla rete Bitcoin una transazione confermata non si annulla: non c'è una banca a cui chiedere lo storno. È la ragione per cui la prima contromisura indicata dal progetto è spegnere il server, interrompendo la possibilità di firmare.

Il contesto delle versioni aiuta a leggere l'episodio. Secondo l'elenco delle release su GitHub, dopo la 2.4.1 del 23 luglio il progetto ha pubblicato una serie di aggiornamenti centrati sulla sicurezza. La 2.4.2 del 7 agosto correggeva una vulnerabilità critica sfruttata attivamente e introduceva, tra l'altro, la disattivazione predefinita dell'autenticazione Basic cinque minuti dopo la creazione dell'account, oltre a chiudere un aggiramento del secondo fattore TOTP. Quella falla, descritta nell'advisory di agosto, consentiva di sottrarre le credenziali dei nodi Lightning LND; l'advisory precisava allora che gli hot wallet on-chain non erano coinvolti. Non risulta dalle fonti primarie consultate se l'attacco attuale sia legato a quella vulnerabilità o a un'altra.

L'ultima release, la 2.4.7 del 29 ottobre, secondo le note di rilascio corregge 85 rilievi segnalati dal programma OSS Scanner di Anthropic: 1 critico, 13 alti, 52 medi e 19 bassi. Il testo raccomanda: «Updating is highly recommended, especially for servers shared by multiple merchants.»

Impatto per investitori retail e istituzionali

Per chi detiene bitcoin in un proprio portafoglio, l'episodio non tocca il protocollo né la rete: riguarda un software applicativo installato da commercianti e servizi. Il rischio è concentrato su chi gestisce un'istanza di BTCPay Server con hot wallet attivo e una versione non aggiornata.

Per i piccoli commercianti e i creatori che usano BTCPay in autonomia, l'impatto può essere immediato: fondi incassati e non ancora spostati su un portafoglio separato potrebbero essere esposti, e lo spegnimento del server significa sospendere gli incassi in bitcoin finché non si aggiorna e si verifica l'istanza. Chi si affida a un provider di hosting potrebbe trovare il servizio già fermato, come indicato dal progetto.

Per gli operatori più strutturati, come piattaforme che ospitano più negozi sulla stessa istanza, la questione è anche di governance: la raccomandazione delle note della 2.4.7 sui server condivisi tra più commercianti indica che proprio quegli ambienti richiedono aggiornamenti tempestivi, controlli sugli account amministrativi e una politica chiara su quanti fondi lasciare sotto il controllo del server.

Rischi e scenari

Il primo rischio è l'incertezza sul perimetro. Il progetto afferma di non avere segnalazioni credibili sulla 2.4.7, ma non ha dichiarato esplicitamente che le versioni intermedie, dalla 2.4.2 alla 2.4.6, siano al riparo, e secondo CoinDesk Dorier non si era pronunciato sulla sicurezza delle versioni più recenti. Finché non sarà pubblicata un'analisi tecnica, la prudenza suggerita dallo stesso progetto resta lo spegnimento o l'aggiornamento.

Il secondo riguarda il modo in cui l'attaccante ha ottenuto l'accesso amministrativo, ancora da chiarire secondo Dorier. Uno scenario possibile, da considerare solo un'ipotesi, è che credenziali o sessioni compromesse in passato siano rimaste valide su istanze non aggiornate: in quel caso aggiornare il software potrebbe non bastare senza una revisione degli utenti amministratori e delle chiavi API.

Un terzo elemento è il precedente di agosto. Secondo Decrypt, dopo quell'incidente alcuni sostenitori avevano finanziato una ricompensa per il recupero pari al 10% dei fondi restituiti, con un tetto di 3 BTC. Una ripetizione ravvicinata di incidenti potrebbe pesare sulla fiducia dei commercianti verso le soluzioni self-hosted, anche se il modello resta quello che evita di affidare i fondi a un custode.

Lo scenario più favorevole è che il problema si dimostri circoscritto a istanze rimaste su versioni vecchie di mesi e che l'analisi tecnica confermi la tenuta della 2.4.7. Lo scenario peggiore, non supportato al momento dalle fonti, sarebbe la scoperta di un difetto ancora aperto nelle release correnti.

Cosa monitorare

• Il resoconto tecnico del progetto: un advisory sulla pagina di sicurezza GitHub o un post sul blog ufficiale dovrebbe chiarire vettore d'attacco, versioni coinvolte e indicatori di compromissione.
• Eventuali nuove release successive alla 2.4.7 e le relative note su GitHub.
• Dati su perdite e istanze colpite, finora non comunicati dal progetto.
• Indicazioni operative per chi riaccende: rotazione di password e chiavi API, revisione degli account amministratori, spostamento dei fondi dell'hot wallet.
• Le comunicazioni dei provider di hosting che hanno spento le istanze in via preventiva.

Pubblicità · link di affiliazione (MEXC, Scalable Capital): se ti registri, CryptoInsights può ricevere una commissione, senza costi aggiuntivi per te.

Scambia su MEXC

Unisciti alla piattaforma leader per il trading di criptovalute con commissioni basse e ottime promozioni!

Registrati ora