Some Keplr users who signed in with Google or Apple have reported unauthorized trades, prompting wallet provider Web3Auth to suspend related services while it investigates a security incident. The issue raises questions not only about account access, but also whether private keys were exposed and how affected assets are being handled. Importing an existing key into another wallet changes the access route; it does not establish that the key remains private.
Web3Auth suspends service, with no confirmed restart
On November 7, Keplr said some accounts created through Google or Apple login had experienced unauthorized trades and suspended both sign-in options. Web3Auth said the same day that it had identified a security issue in its infrastructure affecting some embedded wallets used by Keplr.
Web3Auth’s status notice dated maintenance to November 6 at 18:30 UTC and linked it to the security incident. As of November 8 at 13:08 UTC, the page said an update would be posted once service was restored. Although the listed maintenance window ended on November 7, the notice did not confirm that service had resumed.
A November 7 announcement from MetaMask Builder said its initial investigation had found no impact on MetaMask users. That statement applies to MetaMask and does not clarify the number of affected Keplr accounts or the status of their assets.
Importing a key changes access, not exposure risk
Keplr’s security guidance, updated in September 2025, says Google login accounts use a hexadecimal private key generated by Web3Auth rather than a recovery phrase. The key is encrypted and stored on the user’s device. Keplr’s documentation also describes an option to view the key, though it may not be available for some older accounts. Its mobile guide separately covers Google sign-in and importing accounts with a recovery phrase or private key, and advises users to keep their keys secure.
These standard instructions indicate that a private key can serve as an access method separate from Google login. But the existence of a view or export option does not show that every affected user could retrieve a key while services were suspended. Nor does the documentation verify that an alternative login process worked during this incident.
More importantly, in a follow-up update on November 7, Keplr said private keys belonging to some social-login users had been compromised and that it was working with Web3Auth to secure assets. Keplr said accounts created with a recovery phrase or hardware wallet were unaffected, while Google- or Apple-linked accounts may have been affected. It advised potentially affected users not to send additional funds to those accounts and to move any remaining transferable assets to an account secured with a recovery phrase or hardware wallet.
Importing the same private key into another wallet changes the software used to access the account, not the secret that authorizes transactions. If the key has been exposed, switching interfaces does not establish that others can no longer use it. General instructions for importing a key therefore do not replace Keplr’s incident-specific guidance or provide a solution confirmed to work for every affected account.
Balance changes need to be checked against recovery efforts
Web3Auth said it and its partners had begun a white-hat recovery effort targeting vulnerable Keplr wallets that had not yet been affected, using the original attacker’s route. Keplr said some account balances may have fallen or reached zero as a result of mitigation measures. Staked and locked assets have also complicated the response.
An unfamiliar transfer or a lower balance alone does not establish whether the change resulted from an attack, an asset-protection action or another response. The impact on each account, progress in recovering assets and users’ ability to retrieve private keys must be assessed separately. Even if login services return, that would confirm availability—not, on its own, that private keys are secure or assets have been recovered.