The catch in recovering a hacked crypto wallet: the thief may still have a key

A crypto wallet that lets users sign in with Google or Apple can still lock them out when its login provider stops working. Web3Auth’s security pause has exposed that dependency, alongside a more serious problem: some Keplr users’ private keys may have been compromised. In the wallet app Keplr, a previously saved, usable private key offers a documented route independent of Google login. It does not establish that an incident-affected key remains safe.

On Nov. 7, @keplrwallet reported unauthorized transactions on some accounts created with Google or Apple login and said those login methods were paused. Later that day, @Web3Auth said it had identified a security issue in its infrastructure affecting certain embedded wallets used by Keplr. The disclosures turn a question about login availability into one about what users can still control if an account's key may also be exposed.

Web3Auth's Login Service notice dates maintenance to Nov. 6 at 18:30 UTC and attributes it to a security incident. At 13:08 UTC on Nov. 8, its status page still promised an update when service was restored. The displayed maintenance window ended Nov. 7, but that endpoint did not confirm restoration.

The Nov. 7 MetaMask Builder announcement said an initial investigation found no evidence MetaMask users were impacted.

Keplr's security documentation, updated in September 2025 and still available, says Google-login accounts receive a hexadecimal private key generated through Web3Auth instead of a recovery phrase. It says the key is encrypted and stored locally on the user's device.

The same documentation describes a View Private Key option, subject to exceptions for some legacy accounts. Keplr's mobile import guide separately documents connecting with Google and importing with a recovery phrase or private key. It also tells Google-login users to save their private key securely.

A saved key therefore matters because the documented import route uses that secret directly, separately from Google sign-in. But a menu that normally offers export does not establish that every locked-out user can reach it during this pause. The documented route is not a tested workaround for this incident.

The newer Keplr guidance makes that boundary consequential. In a later Nov. 7 update, @keplrwallet described a private-key breach affecting some social-login users and said it was assisting Web3Auth's ongoing effort to protect assets. It said accounts created with recovery phrases or hardware wallets were not affected, while Google- or Apple-login accounts might be.

For those potentially affected accounts, @keplrwallet advised against sending new funds and said remaining liquid assets should be moved to a recovery-phrase or hardware-wallet account. That guidance concerns moving assets to a different account, a separate action from loading the same key into another app.

Importing the same private key into another interface can change how its owner accesses the account. It does not change the secret authorizing it or establish that nobody else possesses it. Portability can address an access dependency without resolving a confidentiality problem.