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.

What independent access means

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.

Which access condition applies?

Keplr documents private-key import separately from Google sign-in. This compares access routes; it is not an instruction to re-import an affected account.

For potentially affected accounts, Keplr's incident guidance takes precedence over routine re-import instructions.

Keplr's documentation was updated in September 2025. These paths do not verify current export availability or account safety; key exposure and asset recovery remain incident-specific.

Sources and evidence

Sources

1. Keplr key storage and export documentation
2. Keplr separate private-key import route
3. MetaMask Flutter SDK dependencies
4. @keplrwallet initial paused-login statement
5. @keplrwallet updated incident guidance

Supporting facts

• @keplrwallet said on November 7 it had received reports of unauthorized transactions on some accounts created with Google or Apple login and had paused those login methods. [4]
• Reported statement @keplrwallet's later November 7 update described a private-key breach affecting some social-login users and said it was assisting Web3Auth's ongoing asset-protection effort, with staked and locked assets adding complexity. [5]
• Reported statement @keplrwallet said recovery-phrase and hardware-wallet accounts were not affected, while Google- or Apple-login accounts might be affected; its later guidance said not to send new funds and to move remaining liquid assets to a recovery-phrase or hardware-wallet account. [5]
• Keplr's currently available support documentation, updated in September 2025, says Google-login accounts use Web3Auth-generated hex private keys encrypted and stored locally, rather than a recovery phrase. [1] [2]
• Keplr documents a View Private Key option, except for some legacy accounts created in 2020 before that feature, and a mobile import route using a recovery phrase or private key separate from Google sign-in. [1] [2]
• MetaMask's current Flutter SDK documentation describes exporting a private key after sign-in, while initialization checks sessions and fetches project configuration and can throw if that API call fails. [3]
• An already usable local key, a previously saved backup and a fresh provider-dependent login represent different access conditions; the documentation does not establish that every affected user can retrieve a key during the pause. [1] [2] [3]
• Importing the same private key can change the software used for access, but does not change the secret authorizing the account or establish that a potentially exposed key is confidential. [1] [2] [5]

Method

Qualitative dependency diagrams from Keplr's documented key storage/import routes, the current Flutter SDK documentation and attributed November 7 incident statements. No loss estimates, exploit reconstruction or numerical geometry.

Scope

Keplr's documentation was updated in September 2025. These paths do not verify current export availability or account safety; key exposure and asset recovery remain incident-specific.

Infographic by CryptoSlate

Recovery needs its own accounting

@Web3Auth also said it and partners had begun whitehat recovery activities targeting vulnerable Keplr wallets not yet impacted, using the original attacker's path. Separately, @keplrwallet said some reduced or empty balances could reflect mitigation efforts and that staked and locked assets made the work more complex. An unfamiliar transfer or diminished balance alone cannot establish which activity occurred.

Earlier CryptoSlate coverage of the Ledger/Cosmos access outage and Phantom's Sui cutoff showed how wallet interfaces can constrain practical access.

The useful test for a seedless wallet is whether its user has a usable, independent access path before a provider becomes unavailable. During this incident, that question sits alongside unresolved account-level impact and asset recovery. Restoring login service would answer the availability question; it would not, by itself, settle either of the others.