The social-login provider says on-chain movements flagged as theft were partly whitehat recoveries routed to verified addresses
Web3Auth is pushing back on a figure that spread fast across crypto circles: a reported $6.01 million theft from Keplr social-login wallets.
The company says that estimate was false because the funds in question moved to verified recovery wallets, not to an attacker’s pocket.
The dispute matters because it sits on top of a real security incident. A vulnerability in Web3Auth’s services hit Keplr users who signed in with Google and Apple accounts. The open question is how much of the money that left those wallets is actually gone.
What happened to Keplr’s social-login wallets
The trouble started over November 6 and 7, 2026, when funds began draining from Keplr wallets tied to social logins.
Bitquery, a blockchain data provider, tracked more than 44,041 affected wallets in the Cosmos ecosystem. It also tracked 7,603 wallets on Injective, a Cosmos-based chain.
Web3Auth confirmed the vulnerability on November 6 and paused its embedded wallet service the same day.
Keplr co-founder Josh Lee said the breach came from a flaw in Web3Auth’s services. He said it affected roughly 20% of wallets created through Google and Apple logins.
Wallets created the old-fashioned way showed no signs of compromise. According to Keplr, accounts set up with recovery phrases or hardware devices were safe.
For non-specialists, the setup works like this. A social-login wallet lets you open a crypto account with your Gmail or Apple ID instead of writing down a 12- or 24-word seed phrase. A third-party provider, Web3Auth in this case, handles the key management behind the scenes.
Why the $6.01 million figure is contested
The $6.01 million number came from tallying funds that flowed out of affected wallets during the incident window.
Web3Auth’s position is that the tally swept up the wrong transactions. The company says some on-chain movements labeled as theft were actually protective “whitehat” recoveries carried out by Web3Auth and its partners.
The confusion came from how those rescues looked on-chain. The recovery operations used the same technical routes as the initial attacks. To anyone watching the blockchain, a rescue and a robbery looked nearly identical.
By November 8, Web3Auth had published a list of verified recovery addresses. The list covers eleven Cosmos-based networks and eight EVM-compatible chains. The goal was to let users and analysts confirm that recovered assets landed in wallets the company controls.
That list is also what Web3Auth points to when it calls the $6.01 million estimate false. If the money sits in those addresses, the company’s argument goes, it was not stolen.
Official channels only, please
Both Web3Auth and Keplr told users to ignore any unofficial recovery offers. They urged users to rely only on the companies’ own channels for updates and guidance.
Keplr also advised users to stop depositing new funds into affected accounts. It told them to move assets to secure accounts in the meantime.
What this means for social-login wallets
When a user holds their own recovery phrase or a hardware device, their security depends mostly on them. When a provider manages the keys, a single flaw upstream can reach thousands of wallets at once. Keplr’s own guidance underlined that split, since phrase-based and hardware wallets came through untouched.
The dispute over the number also shows a weakness in how crypto incidents get measured in real time. On-chain analytics are fast and transparent, but they show movement, not intent. A rescue that mirrors an attack will be counted as an attack until someone with more context says otherwise.
That cuts both ways. Early estimates can overstate damage, as Web3Auth argues happened here. But a company’s own accounting of its incident also deserves scrutiny, which is why the published recovery addresses matter. They let outsiders check the claim rather than take it on faith.
Disclosure: This article was edited by John Chen. For more information on how we create and review content, see our Editorial Policy.

2 hours ago
22








English (US) ·