Twelve Recovery Wallets Later, Keplr Users Still Have No Explanation for the Key Breach

Keplr’s Saturday morning message was not the kind a wallet company wants to publish. Some accounts created with a Google or Apple login had been sending funds without their owners’ consent. The advice was blunt: stop sending money to those accounts, do not re-import them anywhere, and ignore any link promising a recovery.

By Sunday, the company Keplr named as the source of the problem had published twelve addresses it says are its own recovery wallets. Web3Auth, the wallet infrastructure provider now sold as MetaMask Embedded Wallets, said it had been moving assets out of vulnerable Keplr accounts with Keplr’s assistance, and that some of those transfers had been mistaken for attacker activity.

What neither company has published is the part that matters most to the people who lost access: how the keys were exposed in the first place. No technical root-cause report exists as of Sunday night. The incident is being reconstructed from disclosure posts, product documentation and on-chain traces, and each of those tells a slightly different part of the story.

The Sequence of Disclosures, and What Each One Establishes

Web3Auth moved first, on the evening of Nov 6. “We’re aware of a security issue affecting Web3Auth’s services used by some third parties,” the company posted. “We have temporarily paused the embedded wallet service. After an initial investigation, we’ve found no evidence that MetaMask users are impacted.”

That statement set the boundaries the rest of the response would work inside. It described a provider-level issue rather than a chain-level or wallet-code exploit, and it drew a line around MetaMask’s own users. It did not name the third party involved.

Keplr supplied the name the next morning. “We have received reports of unauthorized transactions on some Keplr accounts created with Google or Apple login,” the wallet wrote. “We flagged this to the @Web3Auth team and have been working with them on the investigation since.” The same post paused Google and Apple logins and told users not to re-import affected accounts.

Keplr cofounder Josh Lee then apologised and separated the codebase from the provider. “This was not a hack of Keplr’s code,” he wrote. “The incident originated at Web3Auth, a provider Keplr uses. All other Keplr accounts, secret recovery phrases, and hardware wallets are safe.” He put the potentially affected share at “about 20%” of accounts created with Google or Apple login, then added a qualifier worth keeping: “I don’t want to be overly optimistic, but it appears only a fraction of that 20% has actually been exploited, and the remaining accounts may be recoverable.”

By Nov 7 Web3Auth had begun what it called whitehat recovery, and the phrasing it chose is the most revealing sentence in the sequence. Its teams targeted “vulnerable but not yet impacted wallets utilizing the same path of the original attacker.” A recovery operation that travels the attacker’s route explains both the speed of the sweeps and the confusion that followed them.

We are aware that some of these transactions have been mistaken for attacker activity. The following are verified recovery addresses used to secure affected assets, not attacker-controlled wallets:

— Web3Auth (@Web3Auth) November 8, 2026

What the Twelve Addresses Actually Show

The published list is the most concrete artifact of the response, and unlike the estimates around it, it can be checked directly. Ten of the twelve addresses sit on Cosmos-family chains, and all ten carry the identical data segment atuap9kfnt6y8ykvn3437e7j3z8qffh3. That is what a single secp256k1 public key looks like when it is rendered under different network prefixes: the same key, wearing a different label on each chain.

Injective is the exception. Its address, inj1lqmdmuczn5rxn5jkc34wwrqdeh70etpf5wvt7g, does not share the segment, which fits an Ethereum-derived 20-byte address rather than a Cosmos-style rendering of the same key. The final entry is a single EVM address that Web3Auth says covers all eight EVM chains in scope.

That shared segment corroborates Web3Auth’s account instead of merely repeating it. Twelve independent attacker wallets would not be controlled by one key. A single recovery key, held by one team and pointed at eleven networks, would look exactly like this.

It also explains the next thing Keplr told users: “some Google/Apple-login accounts may already show a reduced or empty balance as a result of these mitigation efforts.” If a sweep lands in your account history, your balance falls to zero whether a thief or a whitehat signed the transaction.

The Architecture Promised That No Single Party Held the Key

The paradox sits in the documentation. MetaMask’s developer pages describe embedded wallets, “formerly Web3Auth”, as infrastructure that splits a user’s wallet into key shares distributed across OAuth sign-in, trusted devices and recovery factors. “The infrastructure is designed so that no single party holds the full private key,” the architecture page states. Shamir’s Secret Sharing is named as the mechanism that divides the key and reassembles it at signing time, and a core kit “combines key shares to recreate the user’s signing key” once the network validates an ID token.

The same page draws the conclusion users were asked to trust: “This helps keep wallets non-custodial, because no single party (including MetaMask or the login provider) can use a single share to control the wallet.” The model has been consolidating across the industry, with Kraken’s parent acquiring Magic Labs’ embedded wallet business in July, which puts more users behind fewer providers.

Something in that chain did not hold for accounts created with a social login, and the disclosures do not say which link failed. Was a share derivable from the token-validation path? Did share generation produce correlated shares for a subset of accounts? Was the threshold enforced on the client rather than the network? Did a compromised device share plus a provider-side share complete the key? None of these has been confirmed, and each implies a different group of users at risk.

What is confirmed is the outcome. Accounts whose owners never wrote down a seed phrase lost control of keys, and the party holding a share had to walk the attacker’s path to stop the bleeding. Whatever the root cause turns out to be, the incident has already done something no audit report could: it has shown users where the trust in “no single party” actually sits.

Six Million Dollars Is an Estimate, and the Ledger Does Not Settle It

The number most widely repeated is Bitquery’s: at least $6 million drained from more than 44,000 wallets across eight Cosmos networks. Treated as a loss figure, it deserves arithmetic. Six million dollars spread over 44,000 wallets is about $137 per wallet. That is dust, not a treasury.

Either 44,000 addresses held small balances and were swept for whatever was there, or the count includes addresses touched by recovery rather than theft. Both readings point the same way: the aggregate is a sum of many small transfers, and it should not be read as 44,000 users losing meaningful sums.

The recovery side is harder to pin down than it looks. A review of the twelve published addresses by Coinpaper put roughly $5.6 million across them on Sunday, including about 2.49 million ATOM on the Cosmos Hub address. A direct query of that address against a Cosmos Hub node at 23:51 UTC on Nov 8 returned no liquid uatom at all; every balance was denominated in a share token keyed to a validator operator rather than in uatom, spread across roughly 2,000 denominations. Recovery addresses are working accounts, not vaults. Whatever the address held when it was checked has since moved, and any snapshot of it is a moment rather than a total.

Put the two figures side by side and they cannot both describe the same money unless a large part of one is the other. Web3Auth’s own warning that its sweeps were mistaken for theft points at that answer. Some of the “stolen” total is money the recovery team moved, which makes the real loss smaller than $6 million and, as of Sunday night, unpublished.

What Keplr Told Users to Do, and What It Left Undated

The user instructions are specific about liquid balances and silent about time. “Do not send new funds to that account,” Keplr wrote. “Move any remaining liquid assets to a recovery-phrase or hardware-wallet account.” It added the only security advice that matters during an incident of this shape: “Only trust updates from this account or @Web3Auth. Ignore DMs or links offering ‘recovery’.”

For anything staked, bonded or locked, Keplr was explicit that it could not give a date. “This is ongoing,” it said. “Staked and locked assets add complexity and take longer.” A holder with bonded ATOM in an unbonding period, or assets sitting in a contract that cannot be moved with a single signature, is in a queue whose length has not been published.

One instruction is conspicuously absent, and its absence is the design talking. Users are not told to rotate a key, because in a social-login account there is no separate key for them to hold. The account is defined by the identity the provider validates and the shares it manages. That convenience is the product. This week it was also the exposure, and the guidance still does not address what a user should do with a social-login wallet once the incident closes.

An Empty Balance Is Not Proof of Theft

The uncomfortable countercase is that a meaningful share of what looks like theft may be containment. If a transfer left your account for one of the twelve published addresses, the funds were moved by the recovery team. If it left for an address that appears nowhere on the list, the transaction is unresolved, not automatically criminal.

The classification, though, rests entirely on Web3Auth’s own attribution. Neither company has published a reconciled list of transactions, and no independent party has matched the published addresses against the outflows they are supposed to explain. Users are being asked to accept a company’s word about which of its own transfers were protective, in the same week that company’s infrastructure failed. Vendor-side exposure is not unique to this incident: the Chainalysis breach this month exposed live tokens for every user, which is the same lesson at a different layer.

That gap is also where the fraud will gather. A real recovery effort creates a ready-made script for anyone offering “help” in a direct message. Keplr’s warning to ignore recovery offers is not boilerplate caution; it is the predictable sequel to a public list of addresses that thousands of people are now scanning for their own transaction.

ATOM Fell With the Market, Not Because of Keplr

ATOM traded at $1.30 at 23:48 UTC on Nov 8, down 5.2% over 24 hours, according to CoinGecko. Bitcoin was at $74,839, down 1.3%, and ether at $2,131, down 4.7%. The token fell with the market, not out of step with it.

Nothing in the disclosures connects the breach to the price. Cosmos Hub validators kept producing blocks, the recovery addresses moved assets on the same chain as everyone else’s, and the incident sits in wallet infrastructure that most ATOM holders never touch. Traders looking for a causal story will find a coincidence and a headline, and the available evidence does not establish more than that.

What Would Close the Gap

Four disclosures would turn this from a sequence of statements into an accountable record. A root-cause report naming which component exposed the keys, and whether the failure was configuration, share generation or token validation. An extension of the address list, since Web3Auth said it would add verified addresses as it confirmed them. A reconciliation of staked and locked assets with a timetable attached. And a statement from the other integrators, beyond MetaMask’s “no evidence” and Trust Wallet’s assurance that its users were untouched, since both claims are scoped to their own products.

Until those arrive, the honest summary is narrow. A wallet infrastructure provider whose documentation promises that no single party holds a private key lost keys for accounts created through social login, moved assets along the attacker’s own path to contain the damage, and has not yet said which part of the promise broke.