DEV Community

PandaSecurity
PandaSecurity

Posted on Originally published at panda-security.xyz

Keplr Web3Auth Breach: Social Login Keys Exposed

#web3 #wallet #blockchain #security

Originally published at Keplr Web3Auth Breach: Social Login Keys Exposed.

On 6–7 November 2026, Keplr paused Google and Apple login after users reported unauthorized transactions on accounts created through those social sign-in paths. Web3Auth (the Consensys-owned provider behind those embedded wallets, also branded as MetaMask Embedded Wallets) then said it had identified a security issue in its infrastructure affecting certain embedded wallets used by Keplr, leading to a private key breach for some social-login accounts.

This is not a consensus bug and not a Keplr smart-contract exploit. It is an off-chain custody dependency failure: wallets that never showed users a recovery phrase still held spendable keys behind a third-party service. Neither company has published a confirmed loss total or a technical root-cause write-up. Social-media loss figures remain unverified, so we do not repeat them.

TL;DR

  • Target: Keplr accounts created with Google or Apple login via Web3Auth embedded wallets. Dungeon Wallet also warned users about the same Web3Auth incident.
  • Not affected (per Keplr's initial assessment): wallets created with a recovery phrase or a hardware wallet.
  • Timeline: Web3Auth paused embedded wallets at 21:13 UTC on 6 Nov; Keplr's first public warning followed at 04:38 UTC on 7 Nov; both teams described whitehat recovery of vulnerable-but-not-yet-hit wallets later on 7 Nov.
  • Scope hint (not a final count): Keplr co-founder Josh Lee estimated that about 20% of Keplr social-login accounts were affected, and that only a fraction of that set had already been exploited; remaining accounts "may be recoverable."
  • MetaMask consumer wallets: Web3Auth's initial investigation found no evidence MetaMask users were impacted — a preliminary statement, not a completed forensic report.
  • Loss amount: not disclosed by Keplr or Web3Auth. Do not invent one.
  • Root cause detail: not published. Providers describe an infrastructure vulnerability exposing private keys for certain social-login / embedded wallets; no CVE, no bytecode, no verified exploit PoC is public.

What Happened, in Public Order

6 November — Web3Auth pauses embedded wallets

At 21:13 UTC on 6 November 2026, Web3Auth said it was aware of a security issue affecting Web3Auth's services used by some third parties, had temporarily paused the embedded wallet service, and found no evidence that MetaMask users are impacted. The same wording appeared on the MetaMask developer forum. Web3Auth's status page put Login Service into maintenance "due to a security incident." The notice named neither Keplr nor a root cause.

7 November morning — Keplr confirms social-login exposure

At 04:38 UTC on 7 November, Keplr said it had received reports of unauthorized transactions on some accounts created with Google or Apple login, had flagged them to Web3Auth, and was investigating jointly. Its initial assessment was explicit:

  • Recovery-phrase and hardware-wallet accounts are not affected.
  • Google/Apple-login accounts may be affected.
  • Users of those accounts should not send new funds, should not re-import or recreate the account elsewhere, and should treat unsolicited "recovery" DMs as phishing.
  • Google/Apple login was paused.

Keplr co-founder Josh Lee separately said the incident originated at Web3Auth, not from a hack of Keplr's own code, and gave the early ~20% of social-login accounts affected / fraction already exploited estimate cited above. He also said Keplr was working with the Web3Auth and MetaMask team on tracking and recovery, and that the plan for recoverable accounts included a path to move funds to a new recovery-phrase wallet — details to follow.

7 November afternoon — key-breach language and whitehat sweeps

At 16:53 UTC, Web3Auth updated: it had identified a security issue in Web3Auth infrastructure affecting certain embedded wallets used by Keplr, was working with Keplr to secure assets from affected accounts, and warned users to ignore unofficial recovery offers.

Minutes later (17:06–17:07 UTC), Web3Auth said it and partners had begun whitehat recovery on vulnerable but not yet impacted wallets, using the same path as the original attacker. Some of those transfers, it said, had been mistaken for the attacker's; funds recovered that way were described as safe; a verified list of recovery addresses was being prepared so users could tell rescue from theft.

At 17:17 UTC, Keplr restated the boundary and the new guidance for social-login users: assist Web3Auth's effort to secure assets; staked and locked assets take longer; some Google/Apple accounts may already show a reduced or empty balance because of mitigation, not necessarily because of the attacker; move any remaining liquid assets to a recovery-phrase or hardware-wallet account; only trust Keplr and Web3Auth official channels.

An empty balance, in this incident, is therefore ambiguous until Web3Auth publishes its verified recovery-address list and users can match destinations.

Why Social-Login Wallets Fail Differently

A seed-phrase or hardware Keplr wallet keeps key material under the user (or device). A Google/Apple Keplr account, per Keplr support descriptions summarized in secondary reporting, never presented a recovery phrase at creation — Web3Auth generated the key material (commonly described as DKG with encrypted local storage) behind an OAuth button.

That is convenient for beginners. It also changes the blast radius:

  1. The custody boundary moves off the user's device into a vendor. A flaw in the vendor's infrastructure can expose many wallets at once without any user clicking a phishing link.
  2. "Don't re-import" is a real instruction. Until the root cause is public, re-importing the same key into another app may re-expose it. Keplr's early guidance banned re-import for that reason; its later guidance separates that from moving remaining liquid balances out to a fresh recovery-phrase wallet.
  3. Rescue and theft can look identical on-chain. When whitehats and attackers use the same path, destination address lists become part of the security response, not an afterthought.

The theme matches other recent wallet-adjacent failures: signing and key-management infrastructure is security-critical. See our Binance EIP-7702 hot-wallet analysis and Argent-style recovery replay write-up. Keplr/Web3Auth sits upstream of both — the key never needed a buggy module if the issuer already leaked it.

What Builders Integrating Embedded Wallets Should Assume

Treat social-login / MPC / embedded-wallet vendors as in-scope for your threat model, not as a black box that "handles keys for you."

Separate account classes in product and in incident response. Keplr's clearest communication was the split between recovery-phrase / hardware wallets and social-login wallets. Apps that blur those classes in UI or support copy will mis-direct users during a breach.

Plan a migration path before you need it. Lee's "move to a recovery phrase inside Keplr" plan is the right shape: users need a way to leave the compromised issuer without re-importing the same secret into the same compromised path.

Publish recovery destinations early, or users will mislabel rescues as theft. Web3Auth's verified address list is the difference between a chaotic on-chain picture and a readable one.

Do not over-claim MetaMask safety from a preliminary "no evidence" line. That statement was scoped to evidence at pause time. Keplr (named) and Dungeon Wallet (warned) sat inside the affected set.

Reuse a structured review for wallet / AA features. Guardian flows, recovery delays, signature nonces and key-export paths belong on the same checklist as DeFi pricing bugs — see our smart contract security checklist.

# Simplified threat-model sketch. Not Web3Auth or Keplr source.
# user --OAuth--> vendor identity --> DKG / key service --> wallet key
# infrastructure vuln --> key exposure --> attacker spends
# whitehats race the same path on not-yet-hit wallets
# seed / hardware wallets sit outside that issuer path (per Keplr)
Enter fullscreen mode Exit fullscreen mode

What Users Should Do (Per Official Guidance)

  • Recovery phrase / hardware wallet: Keplr's assessment is that you are not affected.
  • Google / Apple login: do not send new funds; move remaining liquid assets to a recovery-phrase or hardware-wallet account; ignore recovery DMs; wait for official check tooling and recovery-address lists.
  • Staked / locked assets may take longer; an empty liquid balance may reflect whitehat mitigation.
  • Trust @keplrwallet and @Web3Auth only.

What Is Still Unknown

  • Exact vulnerability class and subsystem.
  • Confirmed loss total and exact wallet counts beyond Lee's ~20% / fraction-exploited estimate.
  • Full list of third-party apps (Web3Auth said only "some third parties"; Keplr named, Dungeon Wallet warned).
  • Verified whitehat recovery addresses and remittance mechanics (promised, not yet published in sources we used).
  • On-chain tx hashes / attacker addresses were not in the primary posts below — we do not invent them.

Key Facts

Item Value
Primary wallet named Keplr (social login via Web3Auth)
Provider Web3Auth / MetaMask Embedded Wallets (Consensys)
Account class at risk Google / Apple login (embedded) wallets
Account class not at risk (Keplr initial assessment) Recovery phrase, hardware wallet
Web3Auth pause 6 Nov 2026, 21:13 UTC
Keplr first warning 7 Nov 2026, 04:38 UTC
Key-breach + whitehat language 7 Nov 2026, ~16:53–17:17 UTC
Scope hint ~20% of Keplr social-login accounts affected; fraction exploited (Josh Lee)
Confirmed USD loss Not published by Keplr or Web3Auth
MetaMask users No evidence of impact in Web3Auth's initial investigation
Other app note Dungeon Wallet warned users about the same Web3Auth incident

Sources

Closing Thoughts

The Keplr / Web3Auth incident is a reminder that social login is a custody choice, not just a UX choice. Users inherit the vendor's infrastructure risk; builders inherit an incident-response duty they cannot outsource with a status-page sentence. Until a root cause and verified recovery-address list are public, treat social-login balances as potentially exposed, keep seed- and hardware-backed wallets on a separate trust tier, and ignore DM "recovery" offers.

If you ship wallets, account-abstraction modules, or apps that embed third-party social login, talk to our team or review audit pricing before those key paths go live against real user funds.

Top comments (0)