Mise à jour du 8 novembre 2026, 5 h 51 UTC : Keplr a indiqué sur X le samedi 7 novembre à 17 h 17 UTC qu’une vulnérabilité de l’infrastructure de Web3Auth a conduit à une compromission des clés privées de certains utilisateurs connectés avec Google ou Apple. Web3Auth dit avoir lancé avec des partenaires une opération de récupération « white hat » qui a sorti des fonds de portefeuilles vulnérables, ce qui peut expliquer, selon Keplr, certains soldes réduits ou vides. Keplr demande désormais à ces utilisateurs de transférer leurs actifs liquides restants vers un compte à phrase de récupération ou sur portefeuille matériel, ce qui remplace une partie de ses premières consignes. Nous avons réécrit les passages rendus obsolètes par ces déclarations.
Keplr, le portefeuille de l’écosystème Cosmos, affirme qu’une vulnérabilité dans l’infrastructure de Web3Auth, son fournisseur de connexion, a exposé les clés privées de certains utilisateurs inscrits avec Google ou Apple. La société avait suspendu samedi 7 novembre l’inscription et la connexion par compte Google ou Apple, après des signalements de transactions non autorisées sur des portefeuilles Keplr créés de cette façon. Web3Auth, propriété de Consensys, l’éditeur de MetaMask, avait signalé un problème de sécurité sur X dès le 6 novembre à 21 h 13 UTC, puis publié un avis de maintenance de son Login Service sur sa page d’état le 7 novembre à 05 h 53 UTC.
Aucune des deux sociétés n’a dit combien de comptes étaient touchés, quel montant avait été sorti ou mis à l’abri, ni sur quelles blockchains. Les portefeuilles Keplr créés avec une phrase de récupération ou un portefeuille matériel ne sont « PAS concernés », écrit Keplr dans sa dernière déclaration.
Les premiers échos de l’annonce de Keplr dans la presse spécialisée sont apparus samedi peu après 06 h 00 UTC : The Defiant a publié son article à 06 h 12 UTC, puis ChainCatcher et le média chinois Odaily ont suivi dans l’heure.
Les nouvelles consignes de Keplr aux utilisateurs de la connexion Google et Apple
Cette déclaration de Keplr est plus longue que le premier avis. Elle attribue l’incident à une vulnérabilité de l’infrastructure de Web3Auth ayant conduit à une compromission des clés privées (« Web3Auth’s infrastructure vulnerability leading to private key breach ») chez certains utilisateurs connectés avec Google ou Apple, et précise que Keplr aide Web3Auth à mettre à l’abri les actifs des comptes touchés. L’opération est « en cours », écrit la société, et les actifs stakés ou bloqués demandent plus de temps.
Pour les comptes créés avec la connexion Google ou Apple, qui « peuvent être touchés » selon Keplr, la société donne désormais ces consignes :
- Ne plus envoyer de nouveaux fonds vers ce compte.
- Transférer les actifs liquides restants vers un compte à phrase de récupération ou sur portefeuille matériel.
- Ne se fier qu’aux messages du compte X de Keplr ou de celui de Web3Auth.
- Ignorer les messages privés et les liens qui proposent une « récupération ».
La deuxième consigne remplace l’une de celles du samedi matin. Le premier avis de Keplr, relayé par Odaily à 07 h 18 UTC, demandait de ne pas réimporter ni recréer ces comptes dans une autre application ou un autre portefeuille, et la première version de cet article rapportait ce conseil. La déclaration de 17 h 17 UTC ne le reprend pas. Elle vise un compte distinct, doté de sa propre phrase de récupération ou d’un appareil matériel, et ne dit rien d’une importation ailleurs de la clé du compte Google ou Apple. Keplr ajoute qu’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 prépare avec Web3Auth un moyen de vérifier si un compte est touché, sans donner de date.
La récupération « white hat » de Web3Auth explique certains soldes vides
Les soldes vides qui inquiétaient les utilisateurs samedi ne sont pas tous l’œuvre de l’attaquant, disent les deux sociétés. Dans une réponse publiée sur X à 17 h 06 UTC, Web3Auth a indiqué avoir lancé avec des partenaires des « whitehat recovery activities », des opérations de récupération visant les portefeuilles vulnérables mais pas encore vidés, en empruntant le même chemin que l’attaquant initial. Autrement dit, une équipe de secours a utilisé la route de l’attaquant pour sortir les fonds des portefeuilles exposés avant qu’ils ne soient vidés.
Selon Keplr, certains comptes Google et Apple « peuvent déjà afficher un solde réduit ou vide » à cause de ce travail. Un solde vide ne prouve donc pas un vol par l’attaquant. Il ne prouve pas non plus que les fonds sont saufs : aucune des deux sociétés n’a dit quelle part a été déplacée par les secours et quelle part par l’attaquant.
Web3Auth a aussi ouvert à 17 h 06 UTC un fil sur les adresses de récupération, où il demande de ne suivre aucune action ni recommandation hors des sources officielles. D’après KuCoin News, qui reprend The Defiant, et cryptonews.net, Web3Auth y explique que certains transferts de récupération ont été pris pour des mouvements de l’attaquant et qu’il prépare une liste vérifiée des adresses de récupération. « Please do not assume that an unfamiliar destination address is associated with the attacker » (ne supposez pas qu’une adresse de destination inconnue appartient à l’attaquant), a écrit l’entreprise, citée par cryptonews.net. Web3Auth promet d’en dire plus une fois les opérations de récupération terminées, selon les mêmes sources.
Web3Auth reconnaît une faille dans sa propre infrastructure
Web3Auth est passé d’un avertissement général à un constat précis. Son premier message sur X, le 6 novembre à 21 h 13 UTC, parlait d’un problème de sécurité touchant ses services utilisés par « certains tiers », annonçait la suspension du service de portefeuille intégré et disait n’avoir trouvé, après une première enquête, aucun indice que les utilisateurs de MetaMask soient touchés. Le 7 novembre à 16 h 53 UTC, il a écrit avoir identifié « a security issue in Web3Auth infrastructure affecting certain embedded wallets used by Keplr », un problème de sécurité dans son infrastructure touchant certains portefeuilles intégrés utilisés par Keplr. Il n’a nommé aucun autre client, et n’a pas non plus affirmé que les autres étaient épargnés.
La page d’état n’a pas suivi. La maintenance du Login Service n’y compte qu’une mise à jour, horodatée 05 h 53 UTC le 7 novembre : « Nous avons placé le Login Service en mode maintenance en raison d’un incident de sécurité. » La fenêtre prévue allait du 6 novembre, 18 h 30 UTC, au 7 novembre, 18 h 30 UTC. Lors de notre vérification du 8 novembre à 05 h 45 UTC, cette fenêtre était dépassée, l’événement n’affichait toujours que cette mise à jour, sans avis de fin ni de prolongation, et la page principale indiquait le Login Service en panne. Aucune source consultée ne dit que la connexion Google et Apple est rétablie.
La mention de MetaMask s’explique simplement. Consensys a racheté Web3Auth en juin 2025 pour apporter la connexion sociale à MetaMask, et la documentation de Web3Auth se trouve désormais dans les pages « Embedded Wallets » de MetaMask. Le centre d’aide de Keplr indique que les comptes créés par connexion Google reçoivent une clé privée via Web3Auth et, contrairement aux comptes à phrase de récupération, ne peuvent qu’afficher cette clé, sans phrase de récupération.
Ce que l’on ignore encore de l’incident du portefeuille Keplr
L’essentiel de ce qui permettrait de mesurer les dégâts manque toujours. Au 8 novembre, 05 h 45 UTC, ni Keplr ni Web3Auth n’avaient publié le nombre de comptes touchés, le montant pris par l’attaquant ou mis à l’abri par les secours, les chaînes concernées ni la méthode d’attaque. Keplr prend en charge les chaînes Cosmos, mais aussi des réseaux EVM et Starknet : la liste des chaînes possibles est longue.
| Question | Réponse au 8 novembre, 05 h 45 UTC |
|---|---|
| Comptes touchés | Non communiqué |
| Montant pris par l’attaquant | Non communiqué |
| Montant mis à l’abri par la récupération « white hat » | Non communiqué |
| Chaînes concernées | Non communiqué |
| Cause | Vulnérabilité de l’infrastructure de Web3Auth ayant exposé des clés privées, selon Keplr ; méthode non communiquée |
| Autres clients de Web3Auth touchés | Aucun nommé ; les derniers messages de Web3Auth ne citent que Keplr |
| Liste vérifiée des adresses de récupération | En préparation, selon Web3Auth cité par la presse |
| Retour des connexions Google et Apple | Aucune date donnée |
| Plan d’indemnisation | Aucun annoncé |
La cause a désormais un lieu, mais pas encore de mécanisme. Keplr et Web3Auth situent tous deux la faille dans l’infrastructure de Web3Auth. Aucun n’a dit comment l’attaquant a atteint les clés : par les nœuds qui détiennent des morceaux de clé, par l’étape qui transforme une connexion Google ou Apple en morceau de clé, ou par une autre partie du service. La réponse compte pour les nombreuses autres applications qui utilisent le même service, et Web3Auth renvoie les détails à la fin des opérations de récupération.
Portefeuilles à connexion sociale : où sont vos clés, et où ça peut casser
Un portefeuille d’auto-conservation classique, comme Keplr en mode phrase de récupération, ne garde qu’un secret : la phrase, d’où dérivent toutes les clés privées. Qui la détient détient les fonds. Notre guide sur les types de portefeuilles et la conservation détaille ce modèle.
Les portefeuilles à connexion sociale retirent la phrase de la vue de l’utilisateur. Dans la conception standard de Web3Auth, décrite dans sa documentation sur le partage de clé, la clé privée est découpée en trois morceaux par une méthode appelée partage de secret de Shamir, et deux morceaux suffisent à la reconstituer. Un morceau reste sur l’appareil de l’utilisateur. Un deuxième est stocké chiffré et ne s’ouvre que lorsque le réseau de nœuds de Web3Auth vérifie un jeton de connexion Google ou Apple valide. Le troisième est une sauvegarde gardée pour la récupération, par exemple un mot de passe ou un autre appareil. À une connexion normale, le morceau de l’appareil et celui de la connexion sont combinés sur l’appareil, où la clé complète est reconstruite.
Web3Auth vend aussi un kit pour entreprises fondé sur la signature à seuil, une forme de calcul multipartite (MPC), où la clé n’est jamais reconstituée et où les morceaux signent les transactions ensemble. C’est l’approche des sociétés de conservation, expliquée dans notre page sur Fireblocks et la conservation MPC. Keplr n’a pas dit laquelle des deux conceptions ses comptes utilisent.
Dans les deux cas, la promesse est qu’aucune partie seule, ni Web3Auth ni Google, ne peut déplacer les fonds. Les points faibles sont les jointures entre les parties : le service qui transforme une connexion en morceau de clé, le logiciel qui reconstruit ou utilise la clé sur l’appareil, et le compte Google ou Apple qui ouvre la porte. Une faille dans le service commun touche d’un coup toutes les applications qui reposent dessus. Keplr et Web3Auth situent désormais la faille dans l’infrastructure de Web3Auth, ce qui cadre avec le partage observé dès le début par Keplr : les comptes à phrase de récupération ne passent jamais par le service de connexion et sont épargnés, alors que des comptes Google et Apple ont vu leurs clés exposées.
Polymarket : des failles de connexion et de prestataires déjà vues
Les fournisseurs de connexion ont déjà été mis en cause. En décembre 2025, Polymarket a affirmé que des vidages de comptes venaient d’« une vulnérabilité introduite par un fournisseur d’authentification tiers », sans le nommer ; dès septembre 2024, des utilisateurs avaient relié des vidages de comptes à connexion Google sur Polymarket à un SDK de portefeuille externe, cause jamais confirmée. La semaine dernière, une autre dépendance externe, un script de site web, a coûté environ 2,65 millions de dollars aux utilisateurs de Polymarket, comme le raconte notre article sur l’exploit du prestataire de Polymarket.
Keplr est un cas différent, un portefeuille et non un site de paris, mais le point faible se situe de nouveau chez un fournisseur externe. Pour les utilisateurs, cela signifie aussi qu’aucune garantie des dépôts ne vient amortir la perte : dans un portefeuille en auto-conservation, tout remboursement dépend du choix de l’éditeur du portefeuille ou du fournisseur de payer, et ni Keplr ni Web3Auth ne se sont encore exprimés là-dessus.
Deux annonces restent sans date : l’outil de vérification des comptes que Keplr dit préparer avec Web3Auth, et la liste vérifiée des adresses de récupération de Web3Auth. Il manque toujours un chiffre des pertes et une position sur une éventuelle indemnisation. Les connexions Google et Apple restent suspendues, et la page d’état de Web3Auth affichait encore son avis de maintenance dimanche à 05 h 45 UTC, sans heure de reprise.