La pause de Web3Auth expose les utilisateurs Keplr au risque de compromission de clés privées

Web3Auth a suspendu ses services de connexion de portefeuille le 6 novembre à 18h30 UTC à la suite d’un incident de sécurité, une mesure qui a empêché certains utilisateurs de Keplr d’accéder aux comptes créés via la connexion Google ou Apple. Keplr a signalé des transactions non autorisées sur ces comptes de connexion sociale et a indiqué que les clés privées de certains utilisateurs affectés auraient pu être compromises.

L’incident a débuté lorsque Web3Auth a identifié un problème de sécurité dans son infrastructure affectant certains portefeuilles intégrés utilisés par Keplr. Le 7 novembre, l’équipe de Keplr a signalé les transactions non autorisées et a suspendu les méthodes de connexion affectées. La page de statut de Web3Auth, mise à jour à 13h08 UTC le 8 novembre, indiquait que le service n’avait pas encore été rétabli, malgré une fenêtre de maintenance affichée qui s’est terminée le 7 novembre.

Dépendances d’accès et exposition des clés

La documentation de sécurité de Keplr, mise à jour en septembre 2025, explique que les comptes créés avec la connexion Google reçoivent une clé privée hexadécimale générée via Web3Auth plutôt qu’une phrase de récupération standard. Cette clé est chiffrée et stockée localement sur l’appareil de l’utilisateur. La documentation décrit également une option « Afficher la clé privée », bien que des exceptions existent pour certains comptes anciens.

Bien que le guide d’importation mobile de Keplr documente la connexion avec Google et l’importation avec une phrase de récupération ou une clé privée, l’entreprise a noté qu’une clé privée précédemment enregistrée et utilisable offre une voie documentée indépendante de la connexion Google. Cependant, Keplr a précisé que cette voie documentée n’établit pas qu’une clé affectée par l’incident reste sûre. Importer la même clé dans une autre interface change le logiciel d’accès mais ne modifie pas le secret autorisant le compte ni ne prouve qu’aucune autre partie ne le possède.

MetaMask Builder a annoncé le 7 novembre qu’une enquête préliminaire n’avait trouvé aucune preuve que les utilisateurs de MetaMask aient été touchés par l’incident. Keplr a précisé que les comptes créés avec des phrases de récupération ou des portefeuilles matériels n’avaient pas été affectés, tandis que ceux utilisant la connexion Google ou Apple pouvaient l’être.

Protection des actifs et efforts de récupération

Keplr a conseillé aux utilisateurs disposant de comptes potentiellement affectés de ne pas envoyer de nouveaux fonds. L’entreprise a déclaré que les actifs liquides restants devaient être transférés vers un compte de phrase de récupération ou de portefeuille matériel. Cette orientation distingue le transfert d’actifs vers un compte différent du chargement de la même clé dans une autre application, notant que ce dernier ne résout pas les préoccupations de confidentialité.

Web3Auth a déclaré qu’elle et ses partenaires avaient commencé des activités de récupération whitehat ciblant les portefeuilles Keplr vulnérables pas encore touchés. Ces efforts utilisent le chemin de l’attaquant d’origine pour sécuriser les actifs. Keplr a noté que certains soldes réduits ou vides pouvaient refléter ces efforts d’atténuation. L’entreprise a ajouté que les actifs stakés et verrouillés rendaient le travail de récupération plus complexe, ce qui signifie qu’un transfert inconnu ou un solde diminué seul ne peut pas établir quelle activité spécifique s’est produite.

Le rétablissement du service de connexion réglerait la question de la disponibilité pour les utilisateurs, mais il ne trancherait pas les questions non résolues concernant l’impact au niveau du compte ou l’état de la récupération des actifs pour ceux dont les clés auraient pu être exposées.