Keplr Warns Google, Apple Login Wallets Show Depleted Balances

By Marcus Bennett

Some wallets created with Google or Apple sign-in are showing reduced or fully emptied balances, and Keplr says it knows why: a vulnerability in Web3Auth's infrastructure exposed the private keys behind a subset of those accounts. The self-custody wallet's alert tells users to move whatever remains and to stop sending funds to those addresses.

The scene is ordinary, which is what makes it unsettling. A user opens the Keplr app, sees a balance lower than the last session, and checks the chain explorer. The address is the same. The balance is not.

Keplr's guidance is unambiguous. In the alert, the wallet says users should "move any remaining assets and stop sending funds to those accounts," covering both Google-linked and Apple-linked wallets. No figure has been published for the number of affected accounts, the value drained, or the value recovered.

What broke in Web3Auth's infrastructure

The exposure sits one layer below the wallet app. Web3Auth supplies the key infrastructure behind social-login wallets, generating the key material for accounts a user opens with a familiar email or Apple ID rather than a seed phrase. A vulnerability in that infrastructure exposed private keys for some affected accounts, Keplr said.

Web3Auth said it was "working with partners to secure vulnerable wallets that had not yet been attacked through the same path." That phrasing matters. It implies the path was used against some wallets already, and that the remaining exposed accounts were being protected before the same route was tried on them.

The recovery work is a white-hat effort, and it is still running. Balances in affected accounts may be partly reduced or fully emptied while that process continues, which means the damage picture for a given user can change after the alert publishes.

Which wallets are safe?

The clean answer is narrower than the headline suggests. Keplr said accounts created with a recovery phrase or a hardware wallet are not affected. Those setups keep key material on the user's own device, and the flaw in Web3Auth's infrastructure does not reach them.

The exposure is limited to wallets whose keys were derived and held inside the social-login stack:

• Wallets created through Google sign-in
• Wallets created through Apple sign-in
• Any account whose private key was exposed through the vulnerable path

If a user never touched social login and holds a seed phrase or a hardware device, there is no action to take here.

What should affected users do right now?

Keplr's own instructions cover the sequence:

• Move liquid assets to a wallet set up with a recovery phrase or a hardware wallet
• Stop sending funds to affected accounts, including any future deposits
• Treat staked or locked assets as a separate problem, since Keplr said they are harder to move and may take longer
• Wait for the account-check tool that Keplr is building with Web3Auth, which is designed to tell users whether their accounts were affected
• Follow official updates from Keplr and Web3Auth only, and ignore messages or links promising asset recovery

That last point is the standard accompaniment to a key-exposure event. Once balances are visibly wrong, scammers have a ready-made opening, and cloned recovery sites aimed at users who already know something went wrong.

The staked-asset problem deserves emphasis. A user whose balance is locked in a staking position cannot simply sweep the position into a new wallet on the spot. Exit takes time, the delay gives an attacker holding the exposed key a window, and some positions may not be unwindable at all while the underlying protocol operates normally.

What does this change for social-login wallets?

The practical question for a reader who chose convenience over a seed phrase is simple: how much of your own key independence did you actually buy? Social-login onboarding removed the write-down step, and with it removed the user's role in key custody. This incident shows the gap between holding an address and controlling the key behind it.

For the businesses, the operational list is finite and expensive. Web3Auth must rotate or re-derive exposed keys, invalidate sessions tied to vulnerable wallets, and tell affected users which addresses were in the path. Keplr must do account-level triage without publishing a universal fix, because a single update cannot cover wallets with different balances, different staking positions and different exposure dates. Every provider shipping social-login wallets now has to answer the same question in its own incident channel.

There is no compensation figure, no regulator announcement and no lawsuit in Keplr's alert. What exists is a remediation effort and a set of user instructions.

The clock that matters is the recovery window. Keplr and Web3Auth are still building the tool users will need to check their own accounts, and neither has said when it goes live; every minute before that check arrives is another minute in which an attacker holding a derived key can move funds that a white-hat cannot get back.