# Keplr y Web3Auth, 6,01 millones en disputa por la seguridad > Bitquery contó 6,01 millones saliendo de 44.041 carteras de Keplr creadas con Google. Web3Auth dice que eran rescates. La cifra sigue sin cerrarse. > Por José Maldonado · Ciberseguridad · 2026-11-09 Bitquery contó 6,01 millones de dólares saliendo de carteras de Keplr durante la noche del 6 al 7 de noviembre de 2026. Las carteras afectadas tenían algo en común: se habían creado con el botón de Google o con el de Apple, no con una frase de doce palabras. Web3Auth, la empresa que pone la cerradura detrás de esos botones, sostiene que buena parte de ese dinero no lo robó nadie, sino que lo movió ella misma para ponerlo a salvo. El matiz decide si hablamos de un robo de seis millones o de un susto con casi todo recuperado. Una cartera con login social funciona así: el usuario entra con su cuenta de Gmail y el proveedor guarda parte de la llave privada, el código que autoriza los movimientos. Es cómodo y elimina la frase secreta que casi nadie apunta. También concentra el riesgo, porque si falla la pieza compartida fallan miles de monederos a la vez. Web3Auth forma parte de MetaMask desde que Consensys la integró, así que el fallo tocó la infraestructura de uno de los monederos más usados del sector. Las dos empresas pidieron ignorar las ofertas de recuperación ajenas a sus canales, y Keplr recomendó no ingresar fondos nuevos. A 9 de noviembre de 2026 nadie ha publicado un recuento definitivo de pérdidas por usuario, y ese hueco es el centro de la historia. ## Un fallo que pone en jaque la plataforma Web3Auth confirmó el fallo el 6 de noviembre y pausó su servicio de wallets embebidas ese mismo día, hacia las 21:13 UTC, una hora que recoge el relato técnico de la pausa. Al día siguiente, Keplr desactivó los botones de Google y Apple para cortar la sangría. La secuencia es corta: el proveedor apaga, la cartera cierra el acceso, los usuarios descubren saldos vacíos. Entre el aviso y el corte pasaron horas, y en esas horas se movió casi todo el dinero que hoy se discute. Josh Lee, cofundador de Keplr, atribuyó la brecha a un fallo de Web3Auth y no al software de su propia cartera. Su cálculo sitúa el alcance en cerca del 20% de los monederos creados con login social, aunque precisó que solo una fracción había sido explotada. Las carteras con frase de recuperación o con dispositivo hardware quedaron fuera del incidente, un detalle que separa dos formas de entender la custodia. Keplr recomendó a los afectados no depositar fondos nuevos y mover lo que quedara a cuentas seguras. No es un consejo menor, porque si la llave compartida sigue expuesta cualquier ingreso posterior cae en el mismo agujero. La [constelación de actores que sostiene la seguridad de una cartera](https://observatorioblockchain.com/analisis-sociologicos/la-constelacion-de-la-seguridad-dinero-en-tiempos-de-hackeos/) explica por qué un eslabón externo puede tumbar el conjunto aunque el usuario haga todo bien. ## 44.041 wallets, el mapa del daño El rastreo de Bitquery, una firma de datos de cadena, contó 44.041 direcciones afectadas en el ecosistema Cosmos y 7.603 en Injective. Cerca del 86% de las carteras tocadas en siete redes conectadas registraron transferencias después del primer aviso de Keplr. La [investigación de los flujos del 6 y el 7 de noviembre](https://bitquery.io/investigations/keplr-wallet-hack) añade el reparto por red. Cosmos Hub concentra unos 3,50 millones. Osmosis suma 1,04 millones e Injective añade 615.000 dólares. Dos cifras de ese recuento dicen más que el total. La pérdida mediana por cartera fue de 1,34 dólares y la transferencia individual más grande rondó los 325.000. La mayoría perdió calderilla; unos pocos, una casa. El detalle que más incomoda a quien hace staking es otro. Bitquery documentó unos 1,96 millones de ATOM en staking que se movieron sin cumplir el periodo de desbloqueo de 21 días, mediante mecanismos de staking líquido que convierten la posición en un token transferible. Con ese truco, unos 251.000 dólares en recompensas cambiaron de manos. La promesa de que el staking impone una espera de tres semanas se rompió por la puerta de atrás. La lista de redes afectadas también cuenta una historia sobre la concentración. Keplr no es la única cartera del ecosistema, pero sí la puerta de entrada más usada en Cosmos, y un solo proveedor integrado le dio a un fallo el alcance de once redes. Injective lo muestra con claridad: un equipo distinto sufrió el mismo fallo porque compartía proveedor. ## Los 6,01 millones que la empresa considera falsos La cifra que circuló primero salió de sumar todo lo que abandonó las carteras durante la ventana del incidente, con precios del 7 de noviembre. Web3Auth replicó que esa suma mete en el mismo saco dos cosas distintas, robos y rescates. En su versión, parte de las transferencias fueron recuperaciones defensivas que hicieron ella y sus socios hacia direcciones que controlan, y la [respuesta de Web3Auth](https://x.com/Web3Auth/status/2119114303907196932) con la lista de direcciones verificadas llegó el 8 de noviembre con once redes Cosmos y ocho cadenas EVM. La compañía cuantifica su operación en 5,6 millones movidos a doce direcciones de recuperación. Si el dinero está en esas direcciones, su argumento es que no lo tiene un ladrón. La cifra de Bitquery cuenta salidas, no destinos. Nadie fuera de la empresa puede confirmar qué había en cada cartera antes del incidente, y el usuario que ve su saldo a cero no distingue un rescate de un robo. Keplr identificó direcciones de recuperación que coincidían con algunas carteras receptoras examinadas por Bitquery, así que las dos aceptan que hubo rescates y discuten cuántos y por cuánto. El precedente del botín de Binance sirve de espejo en escala menor. Los [3.110 millones que siguen quietos en direcciones del ataque](https://observatorioblockchain.com/criptomonedas/elliptic-botin-binance-3110-millones-sin-mover/) dejaron claro que las cifras de un incidente se miden en varios momentos distintos y que ninguna cuadra con la siguiente. Aquí pasa lo mismo con seis millones y un plazo de cuarenta y ocho horas. ## ¿Por qué un rescate parece un robo en la cadena? Una recuperación defensiva necesita la misma llave que un ataque. Si el problema es que la llave privada quedó expuesta en un servicio ajeno, la forma de sacar los fondos antes que el intruso consiste en usar esa exposición primero. En la cadena, la transacción resultante es idéntica: el saldo sale de la cartera del usuario hacia una dirección que él no controla. De ahí la confusión, y también la oportunidad. Cualquiera que vacíe una cartera puede llamar rescate a lo que hizo, y solo la publicación de las direcciones permite separar una cosa de la otra. El análisis de cadena ve movimientos, no intenciones. Esa limitación tiene dos consecuencias incómodas. La primera es que las estimaciones en caliente tienden a exagerar el daño, como sostiene la empresa. La segunda es que un atacante puede esconderse detrás del relato del rescate y ganar días mientras los afectados esperan instrucciones. La única prueba disponible es una lista de direcciones que publica una de las partes. La pelea por el relato no es nueva. El [roce entre el fundador de OKX y CZ por minimizar un robo](https://observatorioblockchain.com/ciberseguridad/el-fundador-de-okx-acusa-cz-minimizar-robo-binance/) mostró lo rápido que un incidente se convierte en un debate sobre quién lo cuenta peor. Con Keplr y Web3Auth pasa algo parecido, con una diferencia útil: aquí las dos partes publican datos que el usuario puede comprobar. ## Lo que separa una wallet social de la autocustodia La diferencia práctica está en quién puede mover el dinero sin permiso del usuario. Con una frase semilla o un dispositivo hardware, la llave vive con el dueño y el proveedor no tiene nada que firmar. Con login social, una parte de la llave vive en un servidor ajeno y el usuario nunca la ve. La comodidad y el riesgo son la misma pieza. Eso no convierte a la autocustodia en un refugio. Una frase perdida o una firma mal aprobada vacían una cartera igual de rápido, sin empresa a la que reclamar y sin lista de direcciones que consultar. Lo que cambia es dónde aterriza el fallo. En autocustodia el error es del usuario y el alcance es una cartera; con custodia delegada el error es del proveedor y el alcance son decenas de miles. El incidente no demuestra que una opción sea mejor, sino que el riesgo se traslada de sitio cuando se terceriza la llave, y que el usuario rara vez sabe cuánta llave ha entregado. Para estos días, el consejo de ambas empresas es prudente: no ingresar fondos en las carteras afectadas, mover lo que quede y desconfiar de cualquier oferta de recuperación que no venga de sus canales. La pregunta abierta es la de siempre, cuánto de los 6,01 millones volverá a su dueño y en qué plazo. La respuesta no la va a dar un mensaje en redes. Saldrá de conciliar dos listas que ya existen, la de lo que salió de las carteras y la de lo que descansa en las direcciones verificadas, y de aceptar que mientras esa resta no se publique, la etiqueta de robo y la de rescate describen el mismo movimiento.