Keplr and Web3Auth: who substantiates a recovery transfer?
An emptied wallet calls for classifying the transaction before calculating a loss. The Keplr and Web3Auth incident shows why compromised access and reported recovery transfers require separate evidence.
Lire en portugaisBy Pentesty
Start with the account group described by the sources
In a November 7, 2026 statement, Keplr said some accounts created through Google or Apple login could be affected by a Web3Auth infrastructure vulnerability, described as a private-key breach. Keplr excluded wallets created with a recovery phrase or hardware device from its reported scope. That distinction is a company statement about this particular incident.
On November 7, Web3Auth confirmed an infrastructure issue involving certain embedded wallets used by Keplr. That day, it said it began recovery together with its partners using the attacker’s path. On November 8, it reported transfers into recovery wallets with Keplr’s assistance. These are statements by the providers, without independent Pentesty verification of custody over those assets.
Reconcile movements before adding up losses
The November 8 recovery statement identifies destinations that Web3Auth says are recovery addresses rather than attacker-controlled wallets. That identification should accompany examination of each movement. A balance alone does not demonstrate who initiated a transfer or whether the holder has regained access to the assets.
For an enterprise investigation, keep distinct categories: holder-recognized operation, provider-reported transfer, unrecognized operation and movement awaiting classification. Associate the identifier, time, network, consulted evidence and decision owner. Preserve discrepancies between records. Do not publish a theft estimate by adding transfers into recovery destinations, or treat the provider’s statement as an independent audit.
Ask for a confirmation another team can examine
A useful confirmation describes the accounts and operations it covers, who accepts responsibility and which questions remain open. Ask the provider for an authenticated channel to follow the incident, criteria for identifying recovery operations and documentation about returning assets or restoring their availability. An estimated deadline should remain an estimate until the outcome is demonstrated.
Our Trezor, ShipMonk and deletion-evidence analysis concerns a different incident and object. The connection is the scope of an assurance: a generic statement does not identify every copy, account or operation relevant to a business decision. Define specific questions, retain the answers and record who accepted each limitation.
Rehearse resumption without moving real funds
With the responsible teams, establish suspension and resumption criteria for each integration. In an authorized environment, use test accounts and data to verify the permitted path, expected rejection and resulting records. Changes to authentication or recovery need examination alongside the consuming application. The exercise requires neither reproducing exploitation nor moving real assets.
Before acceptance, connect the evidence to the observed environment, configuration and verification time. Keep custody or reconciliation questions visible, with an owner and next action. The BTCPay trust-rebuilding analysis addresses another event and helps distinguish infrastructure recovery from authority that remains attached to a wallet.
Keep communication connected to the evidence
Tell support teams which official sources to consult and how to escalate discrepancies. Unexpected recovery requests should enter the verification procedure, without sharing secrets or following instructions in private messages. Retain the date of each instruction: a later change needs to be distinguished from a decision made using the information available earlier.
The LNbits emergency shutdown requires another acceptance process, focused on the server and authorization to resume service. In both cases, Pentesty proposes turning response into verifiable decisions, explicitly separating what was observed from what still depends on the provider.
Frequently asked questions
Was every Keplr wallet affected?
Keplr limited the risk to some Google- or Apple-created accounts. The company excluded wallets created with a recovery phrase or hardware device from its reported scope.
Does a zero balance prove theft?
It does not identify the cause. Web3Auth reported recovery transfers; investigators need to classify each movement and verify asset availability.
Did Pentesty verify who controls the destinations?
No. Destination identification is attributed to Web3Auth, without our own chain investigation or custody guarantee.
What should an enterprise request before resuming an integration?
Account scope, reconciled operations, responsibilities, resumption criteria and evidence from authorized tests, with open questions recorded.
Sources and references
- Keplr: scope and user guidance, November 7, 2026
- Web3Auth: infrastructure incident, November 7, 2026
- Web3Auth: reported recovery operation, November 7, 2026
- Web3Auth: recovery transfers, November 8, 2026
- Web3Auth: identifying recovery destinations, November 8, 2026
- Web3Auth: updates and fraudulent-request warnings, November 8, 2026
Original Pentesty analysis, published November 9, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.