Web3Auth Flaw Exploited to Steal Keplr Crypto Wallets, Provider Drains Other Accounts for Safety

A security flaw in Web3Auth, the authentication provider that powers social-login wallet creation, was exploited to steal funds from Keplr cryptocurrency wallets created with Google or Apple accounts. Both companies disclosed the incident late last week, and Web3Auth has since taken the unusual step of using the attacker's own access path to empty other at-risk wallets before the attacker could reach them.

What Happened

Keplr is a widely used wallet for the Cosmos ecosystem, and it offers an onboarding option that lets users create a wallet by signing in with an existing Google or Apple account rather than managing a seed phrase. That convenience is delivered through Web3Auth, which converts a familiar OAuth-style login into key material that unlocks the wallet.

The flaw was in Web3Auth's infrastructure, not in Keplr's client software. An attacker who identified the weakness was able to leverage it to reach wallets tied to social-login accounts and move funds out. According to the disclosures, some users who had set up their Keplr wallet with a Google or Apple account lost money as a result.

The Provider's Countermeasure

Rather than simply patching the flaw and waiting, Web3Auth reportedly used the same exploitation route the attacker had employed to access and drain other wallets judged to be at risk, moving the funds out before the attacker could act. The intent was protective: funds in vulnerable accounts were relocated rather than left exposed while remediation proceeded.

That decision is defensible from a loss-prevention standpoint, but it carries significant implications. Users whose wallets were emptied by their own service provider may have found their balances missing without warning, and the legal and trust questions around a provider moving customer assets are considerable. Wallet holders should watch official channels from both Keplr and Web3Auth for instructions on recovering or reclaiming affected balances.

Why Social-Login Wallets Are a Different Risk Profile

Wallets created through Google or Apple sign-in trade self-custody for usability. The private key is not held solely by the user; it is derived or escrowed through a third party's infrastructure, and the security of the wallet is therefore bounded by the security of that provider. This incident is a clear illustration of that dependency: no Keplr user made a mistake, and no seed phrase was phished, yet funds were still taken because a supplier was compromised.

This is not a new debate in the industry. Account-abstraction and social-recovery designs have long argued that mainstream adoption requires removing seed phrases, but every such design introduces a party whose failure becomes the user's loss. The trade-off is not inherently wrong, but it needs to be understood before funds are deposited.

Practical Guidance for Affected and At-Risk Users

• Check official channels first. Keplr and Web3Auth are the authoritative sources for which accounts were affected and how remediation is being handled. Ignore unsolicited messages offering to "restore" or "recover" funds; these are almost always follow-on scams targeting breach victims.
• Review wallet activity. Users who created a Keplr wallet via Google or Apple login should inspect transaction history for transfers they did not authorize and record timestamps and destination addresses.
• Consider migrating to a self-custodial setup. Moving assets to a wallet where keys are generated and stored locally removes the third-party dependency that was exploited here.
• Treat social-login wallets as convenience accounts. If the login method depends on a third party, keep only working balances there and store significant holdings elsewhere.
• Watch for credential-stuffing fallout. Because the affected accounts are tied to Google and Apple identities, enable multi-factor authentication on those accounts and review connected third-party applications.

The Bigger Picture: Supply Chain Risk in Web3

This incident belongs to a familiar pattern in which the weakest point is not the application users interact with but a service it depends on. Wallet providers, bridges, and dApps increasingly rely on authentication and key-management vendors, and a single flaw in that layer can affect many downstream products at once.

For security teams in the sector, the takeaways are concrete. Third-party authentication providers should be assessed not only on uptime and feature set but on key custody model, incident response authority, and whether they can act unilaterally on customer assets. Contracts should define what a provider may do during an active incident, including whether it can move or freeze funds, and how users will be notified.

For users, the episode reinforces a durable rule: convenience and self-custody are different security postures, and the choice should be deliberate rather than default. Where a third party holds or can derive your keys, that party's breach is your breach.

What to Watch Next

Key open questions include the exact technical nature of the Web3Auth flaw, how many wallets were affected, whether the attacker's route has been fully closed, and how funds moved by Web3Auth will be returned to their owners. Users should expect further guidance from both companies and should verify any claims through official domains rather than social media posts.

Original source: The Hacker News – Web3Auth Flaw Exploited to Steal Keplr Crypto