Aggiornamento del 8 novembre 2026, 05:51 UTC: Keplr ha scritto su X alle 17:17 UTC di sabato 7 novembre che una vulnerabilità nell’infrastruttura di Web3Auth ha portato alla compromissione delle chiavi private di alcuni utenti entrati con Google o Apple. Web3Auth dice di aver avviato con alcuni partner un’operazione di recupero «white hat» che ha spostato fondi da wallet vulnerabili, e secondo Keplr questo può spiegare alcuni saldi ridotti o azzerati. Keplr ora chiede a questi utenti di trasferire gli asset liquidi rimasti su un account con frase di recupero o con wallet hardware, sostituendo una parte delle sue prime indicazioni. Abbiamo riscritto i passaggi superati dalle nuove dichiarazioni.
Keplr, 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 wallet di riferimento dell’ecosistema Cosmos, afferma che una vulnerabilità nell’infrastruttura di Web3Auth, il suo fornitore di login, ha esposto le chiavi private di alcuni utenti registrati con Google o Apple. Sabato 7 novembre la società aveva sospeso registrazione e accesso con account Google e Apple, dopo le segnalazioni di transazioni non autorizzate da wallet Keplr creati in quel modo. Web3Auth, controllata da Consensys, la casa di MetaMask, aveva segnalato un problema di sicurezza su X già alle 21:13 UTC del 6 novembre e pubblicato un avviso di manutenzione del Login Service sulla sua pagina di stato alle 05:53 UTC del 7 novembre.
Nessuna delle due società ha detto quanti account siano stati colpiti, quanto sia stato sottratto o messo al sicuro e su quali blockchain. I wallet Keplr creati con una frase di recupero o con un wallet hardware «NON sono coinvolti», ha scritto Keplr nella sua ultima dichiarazione.
Le prime notizie sull’annuncio di Keplr sulla stampa di settore sono comparse sabato poco dopo le 06:00 UTC: The Defiant ha pubblicato il suo articolo alle 06:12 UTC, seguito entro un’ora da ChainCatcher e dal sito cinese Odaily.
Le nuove indicazioni di Keplr per chi usa l’accesso Google o Apple
Questa dichiarazione di Keplr è più lunga del primo avviso. Attribuisce l’incidente a una vulnerabilità dell’infrastruttura di Web3Auth che ha portato alla compromissione delle chiavi private («Web3Auth’s infrastructure vulnerability leading to private key breach») di alcuni utenti entrati con Google o Apple, e spiega che Keplr sta aiutando Web3Auth a mettere al sicuro gli asset degli account colpiti. L’operazione è «in corso», scrive la società, e per gli asset in staking o bloccati serve più tempo.
Per gli account creati con il login Google o Apple, che secondo Keplr «potrebbero essere coinvolti», la società dà ora queste indicazioni:
- Non inviare nuovi fondi a quell’account.
- Spostare gli asset liquidi rimasti su un account con frase di recupero o con wallet hardware.
- Fidarsi solo degli aggiornamenti dell’account X di Keplr o di quello di Web3Auth.
- Ignorare messaggi diretti e link che offrono un «recupero».
La seconda indicazione sostituisce una di quelle di sabato mattina. Il primo avviso di Keplr, riportato da Odaily alle 07:18 UTC, chiedeva di non reimportare né ricreare quegli account in un’altra app o in un altro wallet, e la prima versione di questo articolo riportava quel consiglio. La dichiarazione delle 17:17 UTC non lo ripete. Indica un account distinto, con una propria frase di recupero o un dispositivo hardware, e non parla di importare altrove la chiave dell’account Google o Apple. Keplr aggiunge che sta preparando con Web3Auth un modo per verificare se un account è coinvolto, senza indicare una data.
Il recupero «white hat» di Web3Auth spiega alcuni saldi azzerati
I saldi vuoti che sabato hanno allarmato gli utenti non sono tutti opera dell’attaccante, dicono le due società. In una risposta su X alle 17:06 UTC, Web3Auth ha spiegato di aver avviato con alcuni partner delle «whitehat recovery activities», operazioni di recupero rivolte ai wallet vulnerabili ma non ancora svuotati, sfruttando lo stesso percorso dell’attaccante originale. In pratica, una squadra di soccorso ha usato la strada dell’attaccante per portare via i fondi dai wallet esposti prima che venissero svuotati.
Secondo Keplr, alcuni account Google e Apple «potrebbero già mostrare un saldo ridotto o vuoto» proprio per questo intervento. Un saldo vuoto quindi non dimostra un furto da parte dell’attaccante. Non dimostra nemmeno che i fondi siano salvi: nessuna delle due società ha detto quanto sia stato spostato dai soccorritori e quanto dall’attaccante.
Alle 17:06 UTC Web3Auth ha aperto anche un thread sugli indirizzi di recupero, in cui chiede di non seguire azioni o raccomandazioni che non vengano da fonti ufficiali. Secondo KuCoin News, che riprende The Defiant, e cryptonews.net, Web3Auth vi spiega che alcuni trasferimenti di recupero sono stati scambiati per movimenti dell’attaccante e che sta preparando un elenco verificato degli indirizzi di recupero. «Please do not assume that an unfamiliar destination address is associated with the attacker» (non date per scontato che un indirizzo di destinazione sconosciuto sia dell’attaccante), ha scritto la società, citata da cryptonews.net. Non siamo riusciti ad aprire le risposte del thread, quindi qui l’elenco degli indirizzi non è verificato. Web3Auth promette altri dettagli a operazioni di recupero concluse, secondo le stesse fonti.
Web3Auth indica una falla nella propria infrastruttura
Web3Auth è passata da un avviso generico a una constatazione precisa. Il suo primo post su X, alle 21:13 UTC del 6 novembre, parlava di un problema di sicurezza che toccava i suoi servizi usati da «alcune terze parti», annunciava la sospensione del servizio di wallet integrati e diceva di non aver trovato, dopo una prima indagine, indizi di utenti MetaMask coinvolti. Alle 16:53 UTC del 7 novembre ha scritto di aver individuato «a security issue in Web3Auth infrastructure affecting certain embedded wallets used by Keplr», cioè un problema di sicurezza nella sua infrastruttura che riguarda alcuni wallet integrati usati da Keplr. Non ha nominato altri clienti, né ha detto che gli altri siano al sicuro.
La pagina di stato non si è aggiornata. La manutenzione del Login Service riporta un solo aggiornamento, delle 05:53 UTC del 7 novembre: «Abbiamo messo il Login Service in modalità manutenzione a causa di un incidente di sicurezza». La finestra prevista andava dalle 18:30 UTC del 6 novembre alle 18:30 UTC del 7 novembre. Al nostro controllo delle 05:45 UTC dell’8 novembre la finestra era scaduta, l’evento mostrava ancora solo quell’aggiornamento, senza avvisi di chiusura o di proroga, e la pagina principale indicava il Login Service in interruzione. Nessuna fonte consultata dice che l’accesso con Google e Apple sia tornato.
La menzione di MetaMask ha una ragione semplice. Consensys ha acquistato Web3Auth nel giugno 2025 per portare il login social dentro MetaMask, e la documentazione di Web3Auth oggi si trova nelle pagine «Embedded Wallets» di MetaMask. Il centro assistenza di Keplr spiega che gli account con login Google ricevono una chiave privata tramite Web3Auth e, a differenza di quelli con frase di recupero, possono solo mostrare quella chiave, non una frase di recupero.
Cosa non si sa ancora dell’incidente al wallet Keplr
Manca ancora quasi tutto ciò che servirebbe per misurare il danno. Alle 05:45 UTC dell’8 novembre né Keplr né Web3Auth avevano pubblicato il numero di account coinvolti, l’importo sottratto dall’attaccante o messo al sicuro dai soccorritori, le blockchain interessate o il metodo d’attacco. Keplr supporta le blockchain Cosmos, ma anche reti EVM e Starknet, quindi l’elenco delle catene possibili è lungo.
| Domanda | Risposta alle 05:45 UTC dell’8 novembre |
|---|---|
| Account coinvolti | Non comunicato |
| Importo sottratto dall’attaccante | Non comunicato |
| Importo messo al sicuro dal recupero «white hat» | Non comunicato |
| Blockchain interessate | Non comunicato |
| Causa | Vulnerabilità dell’infrastruttura di Web3Auth che ha esposto chiavi private, secondo Keplr; metodo non comunicato |
| Altri clienti Web3Auth colpiti | Nessuno nominato; gli ultimi post di Web3Auth citano solo Keplr |
| Elenco verificato degli indirizzi di recupero | In preparazione, secondo Web3Auth citata dalla stampa |
| Ritorno del login Google e Apple | Nessuna data indicata |
| Piano di rimborso | Nessuno annunciato |
La causa ora ha un luogo, ma non ancora un meccanismo. Keplr e Web3Auth collocano entrambe la falla nell’infrastruttura di Web3Auth. Nessuna delle due ha detto come l’attaccante sia arrivato alle chiavi: attraverso i nodi che custodiscono i frammenti di chiave, il passaggio che trasforma un login Google o Apple in un frammento di chiave o un’altra parte del servizio. La risposta conta per le molte altre app che usano lo stesso servizio, e Web3Auth rimanda i dettagli alla fine delle operazioni di recupero.
Come i wallet con login social custodiscono le chiavi, e dove possono cedere
Un classico wallet self-custody come Keplr in modalità frase di recupero custodisce un solo segreto: la frase di recupero, da cui deriva ogni chiave privata. Chi la possiede controlla i fondi. La nostra guida ai tipi di wallet e alla custodia spiega nel dettaglio questo modello.
I wallet con login social tolgono la frase dalla vista dell’utente. Nel progetto standard di Web3Auth, descritto nella sua documentazione sulla condivisione della chiave, la chiave privata viene divisa in tre parti con un metodo chiamato Shamir’s Secret Sharing, e bastano due parti per ricostruirla. Una parte resta sul dispositivo dell’utente. Una seconda è conservata cifrata e si sblocca solo quando la rete di nodi di Web3Auth verifica un token di login Google o Apple valido. La terza è una copia di riserva tenuta per il recupero, per esempio una password o un altro dispositivo. In un login normale, la parte del dispositivo e quella del login si combinano sul dispositivo dell’utente e la chiave completa viene ricostruita lì.
Web3Auth vende anche un kit enterprise basato sulla firma a soglia, una forma di calcolo multi-parte (MPC), in cui la chiave non viene mai rimessa insieme e le parti firmano le transazioni congiuntamente. È l’approccio usato dalle società di custodia, come spieghiamo nella nostra pagina su Fireblocks e la custodia MPC. Keplr non ha detto quale dei due modelli usino i suoi account.
La promessa di entrambi i modelli è che nessuna parte da sola, né Web3Auth né Google, possa muovere i fondi. I punti deboli sono le giunzioni tra le parti: il servizio che trasforma un login in un frammento di chiave, il software che ricostruisce o usa la chiave sul dispositivo e l’account Google o Apple che apre la porta. Un difetto nel servizio condiviso tocca in un colpo solo tutte le app costruite su di esso. Keplr e Web3Auth ora collocano la falla nell’infrastruttura di Web3Auth, il che è coerente con la divisione segnalata da Keplr fin dall’inizio: gli account con frase di recupero non passano mai dal servizio di login e non sono coinvolti, mentre alcuni account Google e Apple hanno avuto le chiavi esposte.
Prima di Keplr, i casi di Polymarket con login e fornitori esterni
I fornitori di login sono già stati chiamati in causa. Nel dicembre 2025 Polymarket ha attribuito lo svuotamento di alcuni account a «una vulnerabilità introdotta da un fornitore di autenticazione di terze parti», senza nominarlo; già nel settembre 2024 alcuni utenti avevano collegato gli svuotamenti con login Google su Polymarket a un SDK di wallet esterno, una causa mai confermata. La scorsa settimana un’altra dipendenza esterna, uno script del sito, è costata agli utenti di Polymarket circa 2,65 milioni di dollari, come raccontato nel nostro articolo sull’exploit del fornitore di Polymarket.
Keplr è un caso diverso, un wallet e non un sito di scommesse, ma il punto debole sta di nuovo presso un fornitore esterno. Per gli utenti significa anche che non c’è una garanzia sui depositi a cui appoggiarsi: in un wallet self-custody, un eventuale rimborso dipende dalla scelta del produttore del wallet o del fornitore di pagare, e né Keplr né Web3Auth hanno detto nulla in proposito.
Due annunci restano senza data: lo strumento di verifica degli account che Keplr dice di preparare con Web3Auth e l’elenco verificato degli indirizzi di recupero di Web3Auth. Mancano ancora una cifra delle perdite e qualsiasi indicazione su un rimborso. L’accesso con Google e Apple resta sospeso, e alle 05:45 UTC di domenica la pagina di stato di Web3Auth mostrava ancora l’avviso di manutenzione, senza un orario di ripartenza.