Update, 8 November 2026, 05:51 UTC: Keplr said on X at 17:17 UTC on Saturday 7 November that a vulnerability in Web3Auth’s infrastructure led to a private-key breach for some users who signed in with Google or Apple. Web3Auth says it and its partners began a white-hat recovery operation that moved funds out of vulnerable wallets, which Keplr says may explain some reduced or empty balances. Keplr now tells those users to move remaining liquid assets to a recovery-phrase or hardware-wallet account, replacing part of its first advice. We have rewritten the passages that the new statements made outdated.
Keplr, the Cosmos ecosystem wallet, says a vulnerability in the infrastructure of its login provider Web3Auth exposed the private keys of some users who signed in with Google or Apple. The company paused sign-up and sign-in with Google and Apple accounts on Saturday 7 November, after users reported unauthorized transactions from Keplr wallets created that way. Web3Auth, owned by MetaMask maker Consensys, first reported a security issue on X at 21:13 UTC on 6 November and posted a Login Service maintenance notice on its status page at 05:53 UTC on 7 November.
Neither company has said how many accounts were hit, how much was taken or secured, or on which chains. Keplr wallets created with a recovery phrase or a hardware wallet are “NOT affected”, Keplr said in its latest statement.
The first reports of Keplr’s announcement in the specialist press appeared shortly after 06:00 UTC on Saturday: The Defiant published its story at 06:12 UTC, and ChainCatcher and the Chinese outlet Odaily followed within the hour.
Keplr’s new advice for Google and Apple login users
That statement from Keplr is longer than the first notice. It names the cause as “Web3Auth’s infrastructure vulnerability leading to private key breach” for some users who signed in with Google or Apple, and says Keplr is helping Web3Auth secure the assets of affected users. “This is ongoing,” the company wrote, adding that staked and locked assets take longer.
For accounts created with Google or Apple login, which Keplr says “may be affected”, the company now gives these instructions:
- Do not send new funds to that account.
- Move any remaining liquid assets to a recovery-phrase or hardware-wallet account.
- Trust updates only from Keplr’s account on X or from Web3Auth’s.
- Ignore direct messages and links that offer “recovery”.
The second instruction replaces one from Saturday morning. Keplr’s first notice, as relayed by Odaily at 07:18 UTC, asked users not to re-import or re-create those accounts in any other app or wallet, and the earlier version of this article reported that advice. The 17:17 UTC statement does not repeat it. Its wording points to a separate account that has its own recovery phrase or hardware device; it says nothing about importing the Google or Apple account’s key elsewhere. Keplr adds that it is working with Web3Auth on a way for users to check whether their account is affected, without giving a date.
Web3Auth’s white-hat recovery explains some empty balances
The empty balances that worried users on Saturday are not all the attacker’s doing, the two companies say. In a reply on X at 17:06 UTC, Web3Auth said that, with partners, it had begun “whitehat recovery activities targeting vulnerable but not yet impacted wallets utilizing the same path of the original attacker”. In plain terms, a rescue team used the attacker’s own route to move funds out of exposed wallets before they could be drained.
Some Google and Apple accounts “may already show a reduced or empty balance” because of that work, according to Keplr. An empty balance therefore does not prove theft by the attacker. It does not prove the funds were saved either: neither company has said how much was moved by the rescue and how much by the attacker.
Web3Auth also opened a thread on recovery addresses at 17:06 UTC, telling users not to follow any action or recommendation except from official sources. According to KuCoin News, which relayed The Defiant, and cryptonews.net, Web3Auth said in that thread that some recovery transfers had been mistaken for attacker activity and that it is preparing a verified list of recovery addresses. “Please do not assume that an unfamiliar destination address is associated with the attacker,” it wrote, as quoted by cryptonews.net. Web3Auth said it would share more once recovery operations are complete, according to the same reports.
Web3Auth names a flaw in its own infrastructure
Web3Auth has moved from a general warning to a specific one. Its first post on X, at 21:13 UTC on 6 November, spoke of “a security issue affecting Web3Auth’s services used by some third parties”, said the embedded wallet service was paused and found “no evidence that MetaMask users are impacted” after a first check. At 16:53 UTC on 7 November it wrote that it had identified “a security issue in Web3Auth infrastructure affecting certain embedded wallets used by Keplr”. It has not named any other client, and it has not said that other clients are safe.
The status page has not caught up. Its Login Service maintenance carries a single update, timed 05:53 UTC on 7 November: “We have placed the Login Service into maintenance mode due to a security incident.” The scheduled window ran from 18:30 UTC on 6 November to 18:30 UTC on 7 November. When we checked at 05:45 UTC on 8 November, the window had passed, the event still showed that one update, with no completion or extension notice, and the main page listed the Login Service as being in outage. No source we found says Google and Apple login are back.
The MetaMask mention has a simple reason. Consensys bought Web3Auth in June 2025 to bring social login into MetaMask, and Web3Auth’s documentation now sits under MetaMask’s “Embedded Wallets” pages. Keplr’s help centre says Google-login accounts receive a private key through Web3Auth and, unlike seed-phrase accounts, can only show that key, not a recovery phrase.
What is still unknown about the Keplr wallet incident
Most of what would size the damage is still missing. As of 05:45 UTC on 8 November, neither Keplr nor Web3Auth had published the number of affected accounts, the amount taken by the attacker or secured by the rescue, the chains involved or the attack method. Keplr supports Cosmos chains as well as EVM networks and Starknet, so the list of possible chains is long.
| Question | Answer as of 05:45 UTC, 8 November |
|---|---|
| Accounts affected | Not disclosed |
| Amount taken by the attacker | Not disclosed |
| Amount secured by the white-hat recovery | Not disclosed |
| Chains involved | Not disclosed |
| Cause | A Web3Auth infrastructure vulnerability exposed private keys, according to Keplr; method not disclosed |
| Other Web3Auth clients hit | None named; Web3Auth’s latest posts mention only Keplr |
| Verified list of recovery addresses | Being prepared, according to Web3Auth as reported |
| Return of Google and Apple login | No date given |
| Compensation plan | None announced |
The cause now has a location but not a mechanism. Keplr and Web3Auth both place the flaw in Web3Auth’s infrastructure. Neither has said how the attacker reached the keys: through the nodes that hold key pieces, the step that turns a Google or Apple login into a key piece, or another part of the service. The answer matters for the many other apps that use the same service, and Web3Auth says details will come once recovery is complete.
How social-login wallets hold your keys, and where they can break
A classic self-custody wallet such as Keplr in seed-phrase mode keeps one secret: the recovery phrase, from which every private key is derived. Whoever holds it holds the funds. Our guide to wallet types and custody covers that model in detail.
Social-login wallets remove the phrase from the user’s sight. In Web3Auth’s standard design, described in its key-sharing documentation, the private key is cut into three pieces with a method called Shamir’s Secret Sharing, and any two pieces rebuild it. One piece stays on the user’s device. A second is stored encrypted and is unlocked only when Web3Auth’s network of nodes checks a valid Google or Apple login token. The third is a backup kept for recovery, for example a password or another device. On a normal login, the device piece and the login piece are combined on the user’s device and the full key is rebuilt there.
Web3Auth also sells an enterprise kit based on threshold signing, a form of multi-party computation (MPC), in which the key is never put back together and the pieces sign transactions jointly. That is the approach custody firms use, as explained in our page on Fireblocks and MPC custody. Keplr has not said which of the two designs its accounts use.
The promise of both designs is that no single party, neither Web3Auth nor Google, can move funds alone. The weak points are the joints between the parties: the service that turns a login into a key piece, the software that rebuilds or uses the key on the device, and the Google or Apple account that opens the door. A flaw in the shared service touches every app built on it at once. Keplr and Web3Auth now say the flaw sits in Web3Auth’s infrastructure, which fits the split Keplr reported from the start: seed-phrase accounts never pass through the login service and are unaffected, while some Google and Apple accounts had their keys exposed.
Polymarket’s login and vendor breaches came first
Login providers have been blamed before. In December 2025 Polymarket said account drains came from “a vulnerability introduced by a third-party authentication provider”, without naming it; users in September 2024 had already linked Google-login drains on Polymarket to an outside wallet SDK, a cause never confirmed. Last week a different outside dependency, a website script, cost Polymarket users about $2.65 million, as told in our report on the Polymarket vendor exploit.
Keplr is a different case, a wallet rather than a betting site, but the weak spot again sits with an outside provider. For users it also means there is no deposit guarantee to fall back on: in a self-custody wallet, any refund depends on the wallet maker or the provider choosing to pay, and neither Keplr nor Web3Auth has said anything about that yet.
Two promised items have no date: the account check Keplr says it is building with Web3Auth, and Web3Auth’s verified list of recovery addresses. A loss figure and any word on compensation are still missing. Google and Apple login remain suspended, and Web3Auth’s status page still showed its maintenance notice at 05:45 UTC on Sunday, with no restart time.