Mentioned in This Article
1. What did Web3Auth say about the Keplr losses?
Web3Auth, the company that supplies sign-in infrastructure to wallet apps, said on November 8, 2026, that a widely quoted $6.01 million theft figure tied to Keplr social-login wallets is wrong. The firm says part of the outflow was protective recovery work that moved assets into verified wallets it controls, so those coins were rescued rather than stolen. The vulnerability itself is real.
The disagreement is about accounting rather than about whether a breach occurred. Keplr and Web3Auth both acknowledge a flaw in Web3Auth's services that reached wallets created with Google and Apple sign-ins. What remains unsettled is how much of the money that left those wallets ended up with an attacker and how much ended up in recovery custody.
No official total has been published by either company for the number of affected accounts or the value drained. Independent estimates rest on tracing blockchain transfers, which show that funds moved but cannot show who ordered the movement or why. That limitation sits at the center of the present dispute.
2. How did the Keplr social-login incident unfold?
Wallet draining began on November 6 and continued through November 7, 2026, in Keplr wallets that had been created with social logins. Web3Auth confirmed the vulnerability on November 6 and paused its embedded wallet service the same day, which is the product Keplr relied on for Google and Apple sign-in.
Bitquery, a blockchain data provider, tracked more than 44,000 affected wallets across the Cosmos ecosystem, along with 7,603 wallets on Injective, a Cosmos-based blockchain with the INJ token. Its analysis of transfers out of those wallets during the incident window produced the $6.01 million estimate that Web3Auth now contests.
Cosmos is a network of interoperable blockchains, and Keplr is one of the most widely used wallets for it. A single Keplr account can hold assets on many of those chains, which helps explain why Bitquery counted affected wallets across the wider ecosystem and not on one network alone. The same convenience means that one compromised key can expose balances in several places at once.
Keplr co-founder Josh Lee said the breach originated in a flaw in Web3Auth's services rather than in Keplr's own software. He estimated that roughly 20% of the wallets created through Google and Apple logins were affected. Keplr also reported that wallets set up with a recovery phrase, or backed by a hardware device, showed no signs of compromise.
Keplr suspended Google and Apple sign-in for its wallet while recovery efforts proceeded. Neither company had disclosed the precise technical cause of the flaw as of November 8, and that gap leaves outside observers with limited means of judging how the exposure happened or whether it has been fully closed.
3. Why can a rescue look like a theft on the blockchain?
A rescue and a theft can look almost identical on a public ledger, because both consist of assets leaving a wallet for another address. Blockchain data records the transfer, the amount and the destination; it does not record intent. An analyst totaling every outbound movement during an incident therefore counts defensive transfers alongside malicious ones unless the destination addresses are already known.
Web3Auth's argument rests on exactly this point. The company says some of the movements that were classed as theft were whitehat recoveries carried out by Web3Auth and its partners. Because those operations used the same technical routes as the original attacks, they resembled the attacks closely when viewed on-chain.
The term whitehat refers to security practitioners who act to protect assets rather than to take them. In an incident where private keys are exposed, a defender's fastest option can be to sweep funds out of exposed wallets before an attacker does, then hold them at addresses that only the defender controls. The cost of that approach is that users see balances disappear and must trust the party that moved them.
Keplr acknowledged this side effect in its own notice, saying that some social-login accounts were affected by a whitehat rescue and that assets in those accounts might be reduced or cleared. Users who looked at their wallets and found them empty could not tell from the balance alone which kind of transfer had occurred.
4. What proof has Web3Auth offered?
By November 8, Web3Auth had published a list of verified recovery addresses covering eleven Cosmos-based networks and eight EVM-compatible chains. The company's position is that anyone, including analysts and affected users, can check those addresses and confirm that the assets sit in wallets under its control.
Web3Auth presents the list as direct evidence against the $6.01 million estimate: if funds are held at those addresses, it argues, they were not taken by an attacker. A published address list makes the claim testable, since a transfer into a listed address can be matched against the company's statement.
The claim still needs independent confirmation. Web3Auth is both a party to the incident and the source of the recovery figures, and the company has not stated a total for the amount recovered or broken down how much of the disputed sum falls into each category. Until an outside party reconciles the addresses against the transfers, the real loss figure remains uncertain.
The dispute therefore cuts in two directions. Early estimates built from raw transfer data can overstate losses, which is the point Web3Auth makes. At the same time, a company's own accounting of its recoveries deserves scrutiny, which is why the open publication of addresses matters.
5. What does a social-login wallet do, and where is the risk?
The incident also touches a broader question about how wallet apps are built. Many teams prefer to license sign-in infrastructure instead of writing it, because key management is difficult and errors are costly. That choice saves effort, yet it ties the security of every dependent app to the supplier, and a flaw at the supplier becomes a flaw in each product that uses it.
Security researchers generally advise users to weigh convenience against control when choosing how to hold assets. Social login suits small balances and beginners, whereas larger holdings are usually better kept behind a hardware device or a recovery phrase stored offline. The Keplr episode gives that guidance a concrete example, since the accounts that used recovery phrases or hardware devices were reported as unaffected.
Timing matters for rescue operations as well. Once keys are exposed, defenders and attackers race to move the same assets, and whoever acts first determines where the funds land. That race is why a protective sweep can resemble an attack, and why Web3Auth says its partners had to use the same technical routes as the attackers, which in turn is why the dispute over the figure arose.
A social-login wallet lets a person open an account with an existing Gmail or Apple ID instead of writing down a 12-word or 24-word seed phrase. A third party, in this case Web3Auth, manages key handling in the background. The design removes the hardest step for newcomers, which is safeguarding a recovery phrase, and has made it common in consumer wallet apps.
The trade-off is that responsibility shifts from the individual to the provider. A person who holds a seed phrase or a hardware device carries the security burden personally, and a mistake affects only that person. A provider that manages keys for many apps concentrates that burden, so one upstream flaw can reach thousands of wallets at once, as the Keplr incident illustrates.
Keplr's own guidance mirrored the split. The company said wallets created with recovery phrases or hardware devices showed no signs of compromise, while the exposure fell on accounts that depended on the social-login route. The distinction gives users a concrete way to understand why some wallets were touched and others were not.
6. What should affected Keplr users do now?
Web3Auth and Keplr both told users to rely only on official company channels and to ignore unofficial offers to recover funds. Incidents of this kind tend to attract impersonators who promise to return lost assets in exchange for a seed phrase, a signature or a fee, and any such contact should be treated as a scam.
Keplr also advised users to stop depositing new funds into affected accounts and to move assets to secure accounts in the meantime. That advice applies particularly to anyone who still holds balances in a wallet created with a Google or Apple login, because the flaw that exposed keys may not yet be fully closed.
Users who find a zero balance should check the published recovery addresses before assuming their funds were taken by an attacker, since the company says that part of the missing assets sits there. They should not, however, send assets or credentials to any address or website that was not announced through the official channels of the wallet provider.
7. What happens next in the Keplr and Web3Auth dispute?
Several points remain open. Neither company has published the exact technical cause of the vulnerability, an official count of affected accounts, or a final figure for assets recovered versus assets lost. Those details would let outside researchers settle whether the $6.01 million estimate was too high, about right, or too low.
The timeline for restoring service is also unclear. Web3Auth paused its embedded wallet service on November 6, and Keplr suspended Google and Apple sign-in. Neither has announced a date for resuming either feature, and the decision will likely depend on how thoroughly the underlying flaw is fixed.
For the wider industry, the episode shows how difficult it is to measure a crypto incident while it is still in progress. Early on-chain tallies are quick to circulate and slow to correct, and a figure that spreads on the first day can persist long after the facts change. A transparent reconciliation, with recovery addresses open to inspection, is the clearest way to resolve the disagreement.