The first sign was a balance. Keplr users who had created their wallet with a Google or Apple account woke up on November 6 to find funds gone, and no transaction they remembered approving.
There was no phishing site, no malicious signature, no seed phrase typed into the wrong window. The common factor was how the wallet had been created: through a login button, run by a company called Web3Auth. Both companies confirmed the incident late last week. Keplr described it as a private key breach caused by a flaw in Web3Auth’s infrastructure. Web3Auth called it a security issue in its own infrastructure affecting certain wallets it provides inside the Keplr app (The Hacker News).
That distinction matters more than the dollar figure. This was not a user making a mistake. It was a custody model failing at the layer almost nobody inspects.
What happened on November 6
The sequence, as far as either company has described it:
Web3Auth disclosed that a security issue in its infrastructure affected wallets it provides inside Keplr. Keplr went further and said the flaw led to a private key breach for users who signed in with Google or Apple (Keplr).
On November 6, Web3Auth disabled its embedded wallet service. The next day it began what it describes as a protective operation: accessing vulnerable accounts through the same route the attacker used, and moving the funds to addresses it controls. On November 8 it published 12 recovery addresses so users could distinguish its transfers from an attacker’s (Web3Auth).
Keplr paused Google and Apple sign-in and told users not to deposit to affected accounts, not to re-import or recreate them, and to move unstaked funds to an account backed by a recovery phrase or hardware wallet. Wallets created with a seed phrase or a hardware device were not affected.
The timing is uncomfortable. According to Bitquery’s data, the first of the rescue transfers happened 21 minutes before Web3Auth’s first public notice, and 86% of the wallets were emptied after Keplr had already warned users. Both facts are consistent with a team racing an attacker through a door it had just found, but they also mean most users watched their balance drop with no statement yet explaining why.
The custody model behind a login button
A social-login wallet is not self-custody in the sense most people mean.
When you create a Keplr account with Google, the key is not generated on your phone and stored there. Web3Auth splits the key material into shares, holds them in its infrastructure, and releases what is needed to sign after your OAuth login proves who you are. The user experience is excellent: no seed phrase to write down, no 24 words to lose, wallet recovery is a login.
The trade is explicit and usually invisible. You are not the only party that can move the funds. A flaw in the layer that assembles your key is a flaw in every wallet that uses it, which is why one bug reached tens of thousands of accounts on a Friday.
Keplr’s co-founder Josh Lee estimated that about 20% of accounts created through Google or Apple were affected, and that only a fraction of those were actually exploited. He also said the wallet’s own code was not compromised (Josh Lee).
The pattern is familiar from earlier incidents in this publication’s reporting: the Fearless Wallet extension leak and the Ledger supply-chain case were both about key material escaping the place it was supposed to stay. The difference here is where it lived. Not on a device, not on a chip, but in a login provider’s key-share service.
The numbers, and why they disagree
Three figures are circulating, and none of them is the loss.
GoPlus, a Web3 security firm, said at least about $1 million had been stolen, without explaining how the figure was derived (GoPlus).
Bitquery counted at least $6.01 million moving out of more than 44,000 wallets. Its breakdown: 44,041 addresses across seven Cosmos-ecosystem chains plus 7,603 addresses on Injective, which after removing overlaps comes to roughly 44,700 unique wallets (Bitquery).
Web3Auth says it moved approximately $5.6 million into recovery wallets across 11 Cosmos-family chains and eight Ethereum-style chains.
Read them together and the shape is: a large sweep, most of it performed by the provider rather than the attacker, with an unknown fraction taken by the attacker first. Bitquery’s own correction says as much. Its first report called the transfers theft, then it reclassified them as the rescue, while stating that it cannot verify who controls the recovery addresses.
One detail explains why the operation was complicated. Most of the rescued value was ATOM on Cosmos Hub, around 2.49 million tokens worth roughly $3.3 million, and much of it was staked. Unbonding on Cosmos Hub takes 21 days. A wallet the attacker can still reach is not a place to wait three weeks, so the team swapped staked positions into liquid tokens that could move immediately (ForkLog).
Theft and rescue look identical on-chain
This is the part worth remembering the next time a breach unfolds in public.
On-chain, a rescue is indistinguishable from a theft. Funds leave your address and arrive at an address you do not control. The transaction is valid, signed with your key, and there is no memo explaining intent. Analysts reconstruct intent afterwards from who published what, when, and from address clustering that is itself an inference.
Bitquery did the honest thing: it published a correction and said what it could not verify. But the first version travelled further than the correction will, which is normal. If you were watching a tracker or a Telegram alert channel over the weekend, the number you saw first was probably wrong.
The practical rule for readers: during the first 48 hours of a key-compromise incident, treat address labels as provisional. Check whether the destination appears on the provider’s own recovery list before concluding anything, and do not join a class action, pay a recovery fee, or send documents to anyone who contacted you first.
What affected users should do now
Keplr’s guidance, in order of urgency:
Do not send new funds to a social-login account. Do not re-import it or recreate it anywhere; the key behind it is the thing that was exposed. Move anything not staked or locked to an account backed by a recovery phrase or a hardware wallet, and keep that new account’s phrase offline.
Staked assets are the exception that requires patience and a decision. Unbonding takes 21 days on Cosmos Hub, and the position stays reachable during that window. Keplr says staked and locked assets are taking longer to secure and that it is working with Web3Auth on a per-account checker. If you are in that position, start the unbonding now and treat the destination address as the thing you control, not the wallet you are leaving.
Ignore every message offering help. The recovery scams that follow a public incident are already the subject of a separate guide. No legitimate team asks you to import a key into a site to verify it, and no one needs your seed phrase to return funds.
If your wallet was created with a seed phrase, the answer is simpler: nothing here applies to you. That is not a moral about self-custody being superior in the abstract. It is a concrete difference in blast radius, and this week it was the difference between being affected and reading about it.
What is still unexplained
Neither company has said how the flaw worked, when the attacker first used it, or whether the route is closed. Web3Auth’s status page still listed its login service as down at the time of writing, and its embedded wallet service, which other apps use to build wallets for their users, was paused. Web3Auth says the issue affects services it provides to other companies, but Keplr is the only one it has named.
Consensys, which owns MetaMask, acquired Web3Auth in June 2025 specifically to bring social logins into MetaMask. Web3Auth says its initial investigation found no evidence that MetaMask users are impacted. That claim deserves the same scrutiny as the rest: it is a statement about an investigation that is still running, not a result.
The loss figure will settle in the coming weeks. The more important number is 44,000, and it will not change: that is how many wallets depended on one company’s key infrastructure to keep working, and how many were reachable through a single flaw.
Sources
- The Hacker News — Web3Auth flaw exploited to steal Keplr crypto (November 9, 2026)
- Keplr user guidance and co-founder’s initial findings
- Web3Auth recovery address list and status page
- Bitquery investigation (first report and correction)
- GoPlus security alert
- ForkLog — Web3Auth transfers $5.6 million from vulnerable Keplr wallets (November 9, 2026)
- Consensys — acquisition of Web3Auth
Frequently Asked Questions
Was my Keplr wallet affected?
Only wallets created with the Google or Apple sign-in were exposed. If your Keplr account was set up with a 12 or 24 word recovery phrase, or with a hardware wallet, Keplr says it is not affected. Social logins were paused on November 6. Keplr and Web3Auth have both said a checker is coming, and Web3Auth has published the list of recovery addresses it used, so a balance that reads zero is not proof of theft.
How does a Google login hold a private key?
In a social-login wallet the key is not stored on your device. Authenticating with Google or Apple proves who you are, and the key is then assembled from shares held by the provider's infrastructure. Web3Auth runs that layer for Keplr. It means there is no recovery phrase to lose, and also that a flaw in one company's infrastructure can reach every wallet that trusted it.
How much was actually stolen?
Nobody has published the loss figure. GoPlus said at least about $1 million was stolen without explaining the method. Bitquery counted at least $6.01 million moving out of more than 44,000 wallets, then corrected its analysis to treat most of those transfers as Web3Auth's rescue operation. Web3Auth says it moved approximately $5.6 million to recovery wallets. The three numbers measure different things.
Why do some reports call it theft and others a rescue?
Because the two look the same on-chain. Web3Auth accessed vulnerable accounts the way the attacker did and swept funds to addresses it controls. Bitquery's first report called those transfers theft; its correction says they were the rescue, while admitting it cannot verify who controls the recovery wallets. Web3Auth published 12 addresses on November 8 so users can tell its transfers apart from an attacker's.
Will users get the rescued funds back?
Web3Auth says the moved assets are safe and that it is working with Keplr to return them. Neither company has said how or when. Staked assets are the hard part: most of the rescued value was ATOM, and unbonding on Cosmos Hub takes 21 days, so the team swapped staked positions into liquid tokens before moving them.
What should I do if I used a social login?
Do not send new funds to that account, and do not re-import or recreate it anywhere. Move anything that is not staked or locked to an account backed by a recovery phrase or a hardware wallet. If funds are staked, start unbonding now rather than waiting for a full explanation. Ignore anyone offering recovery help in a direct message, including people claiming to be from Keplr or Web3Auth.