Algunos usuarios de Keplr que accedían con Google o Apple han denunciado operaciones no autorizadas. El proveedor de la cartera, Web3Auth, suspendió los servicios relacionados mientras investiga un incidente de seguridad que podría haber expuesto claves privadas y comprometer los activos de las cuentas afectadas. Importar una clave a otra cartera cambia la forma de acceso, pero no demuestra que esa clave siga siendo confidencial.
Web3Auth suspende el servicio sin confirmar su restablecimiento
El 7 de noviembre, Keplr informó de operaciones no autorizadas en algunas cuentas creadas mediante el inicio de sesión con Google o Apple y deshabilitó ambas opciones. Ese mismo día, Web3Auth comunicó que había detectado un problema de seguridad en su infraestructura que afectaba a algunas carteras integradas utilizadas por Keplr.
El aviso de estado de Web3Auth situó el inicio del mantenimiento el 6 de noviembre a las 18:30 UTC y lo vinculó al incidente de seguridad. A las 13:08 UTC del 8 de noviembre, la página indicaba que se publicaría una actualización una vez restablecido el servicio. Aunque el periodo de mantenimiento señalado concluía el 7 de noviembre, el aviso no confirmaba que el servicio ya estuviera operativo.
En un comunicado del 7 de noviembre, MetaMask Builder señaló que su investigación inicial no había detectado efectos sobre los usuarios de MetaMask. Esa declaración se refiere a MetaMask y no aclara cuántas cuentas de Keplr están afectadas ni cuál es la situación de sus activos.
Importar la clave no elimina el riesgo de exposición
La guía de seguridad de Keplr, actualizada en septiembre de 2025, indica que las cuentas con acceso de Google utilizan una clave privada hexadecimal generada por Web3Auth, en lugar de una frase de recuperación. La clave se cifra y se guarda en el dispositivo del usuario. La documentación de Keplr también describe una opción para consultar la clave, aunque puede no estar disponible en algunas cuentas antiguas. Por separado, la guía móvil explica cómo iniciar sesión con Google e importar cuentas mediante una frase de recuperación o una clave privada, y recomienda mantener las claves protegidas.
Estas instrucciones generales muestran que la clave privada puede servir para acceder a la cuenta sin depender del inicio de sesión con Google. Sin embargo, que exista una opción para consultar o exportar la clave no demuestra que todos los usuarios afectados pudieran obtenerla durante la suspensión de los servicios. La documentación tampoco confirma que una vía alternativa de acceso funcionara durante el incidente.
En una actualización posterior, el 7 de noviembre, Keplr indicó que las claves privadas de algunos usuarios que iniciaban sesión con redes sociales habían quedado comprometidas y que trabajaba con Web3Auth para proteger los activos. La empresa afirmó que las cuentas creadas con una frase de recuperación o una cartera física no se habían visto afectadas, mientras que las vinculadas a Google o Apple podrían estarlo. Recomendó a los usuarios potencialmente afectados no enviar más fondos a esas cuentas y trasladar los activos transferibles restantes a una cuenta protegida con una frase de recuperación o una cartera física.
Importar la misma clave privada a otra cartera cambia el programa utilizado para acceder a la cuenta, no el secreto que autoriza las operaciones. Si la clave se ha expuesto, cambiar de interfaz no garantiza que terceros hayan perdido la capacidad de usarla. Por eso, las instrucciones generales para importar claves no sustituyen las indicaciones específicas de Keplr para este incidente ni constituyen una solución confirmada para todas las cuentas afectadas.
Las variaciones de saldo deben analizarse junto con la recuperación
Web3Auth dijo que, junto con sus socios, había iniciado una operación de recuperación de activos de tipo white hat dirigida a carteras vulnerables de Keplr que aún no habían sido afectadas, utilizando la misma vía que el atacante original. Keplr advirtió que los saldos de algunas cuentas podían haber disminuido o llegado a cero como resultado de las medidas de mitigación. Los activos en staking o bloqueados también han complicado la respuesta.
Una transferencia desconocida o un saldo menor, por sí solos, no permiten determinar si el cambio se debió a un ataque, a una medida de protección o a otra acción de respuesta. El impacto en cada cuenta, los avances en la recuperación de activos y la posibilidad de que los usuarios obtengan sus claves privadas deben evaluarse por separado. Aunque se restablezca el inicio de sesión, eso solo confirmaría que el servicio está disponible; no demostraría por sí mismo que las claves sean seguras ni que los activos se hayan recuperado.