Keplr e Web3Auth: quem comprova o destino de uma transferência de recuperação?
Uma carteira esvaziada exige identificar a operação antes de calcular a perda. O caso Keplr e Web3Auth mostra como separar o acesso comprometido das transferências declaradas de recuperação.
Read in EnglishPor Pentesty
Comece pelo grupo de contas descrito nas fontes
Em comunicado de 7 de novembro de 2026, a Keplr disse que algumas contas criadas com login Google ou Apple poderiam ser afetadas por uma vulnerabilidade na infraestrutura da Web3Auth, descrita como comprometimento de chaves privadas. A Keplr excluiu do escopo informado as carteiras criadas com frase de recuperação ou dispositivo de hardware. Essa delimitação é uma declaração sobre este incidente.
Em 7 de novembro, a Web3Auth confirmou um problema em sua infraestrutura envolvendo determinadas carteiras integradas usadas pela Keplr. No mesmo dia, declarou ter iniciado, em conjunto com seus parceiros, a recuperação usando o caminho do atacante. Em 8 de novembro, informou transferências para carteiras de recuperação com ajuda da Keplr. São relatos dos fornecedores, sem verificação própria da Pentesty sobre a custódia desses ativos.
Reconcilie movimentos antes de somar perdas
O comunicado de recuperação de 8 de novembro identifica destinos que a Web3Auth declara serem de recuperação, em vez de controlados pelo atacante. Essa identificação deve acompanhar a análise de cada movimento. O saldo sozinho não demonstra quem iniciou uma transferência nem se o titular recuperou a disponibilidade dos ativos.
Na apuração empresarial, mantenha categorias distintas: operação reconhecida pelo titular, transferência declarada pelo fornecedor, operação não reconhecida e movimento ainda sem classificação. Associe identificador, horário, rede, evidência consultada e responsável pela decisão. Preserve divergências entre registros. Não publique uma estimativa de roubo agregando valores movidos para destinos de recuperação, nem trate uma declaração do fornecedor como auditoria independente.
Peça uma confirmação que outra equipe consiga conferir
Uma confirmação útil descreve quais contas e operações abrange, quem assume a responsabilidade e quais dúvidas continuam abertas. Solicite ao fornecedor um canal autenticado para acompanhar o caso, critérios para identificar operações de recuperação e documentação sobre a devolução ou disponibilidade dos ativos. Um prazo estimado deve continuar identificado como estimativa até haver comprovação do resultado.
Nosso texto sobre Trezor, ShipMonk e evidências de exclusão discute outra ocorrência e outro objeto. A relação está no alcance da confirmação: uma garantia genérica não identifica todas as cópias, contas ou operações que uma decisão empresarial precisa considerar. Defina perguntas específicas, preserve as respostas e registre quem aceitou cada limite.
Ensaie a retomada sem movimentar fundos reais
Com os responsáveis, estabeleça critérios para suspender e retomar cada integração. Em ambiente autorizado, use contas e dados de teste para verificar o caminho permitido, a rejeição esperada e os registros produzidos. Mudanças de autenticação ou recuperação precisam ser examinadas juntamente com a aplicação consumidora. O exercício não exige reproduzir a exploração nem movimentar ativos reais.
Antes do aceite, relacione as evidências ao ambiente observado, à configuração e ao momento da verificação. Mantenha pendências de custódia ou reconciliação visíveis, com responsável e próxima ação. A análise de reconstrução de confiança no BTCPay aborda um evento diferente e ajuda a separar recuperação de infraestrutura da autoridade que permanece sobre uma carteira.
Mantenha a comunicação ligada à evidência
Informe às equipes de atendimento quais fontes oficiais consultar e como encaminhar divergências. Pedidos inesperados de recuperação devem entrar no procedimento de verificação, sem compartilhar segredos ou seguir instruções por mensagem privada. Preserve a data de cada orientação: uma mudança posterior precisa ser distinguida da decisão tomada com a informação disponível anteriormente.
A parada emergencial do LNbits exige outro tipo de aceite, centrado no servidor e na autorização para retomar o serviço. Nos dois casos, a proposta da Pentesty é transformar a resposta em decisões verificáveis, mantendo explícito o que foi observado e o que ainda depende do fornecedor.
Perguntas frequentes
Toda carteira Keplr foi afetada?
A Keplr delimitou o risco a algumas contas criadas com Google ou Apple. Carteiras criadas com frase de recuperação ou hardware foram excluídas do escopo informado pela empresa.
Saldo zero comprova que houve roubo?
Não identifica a causa. A Web3Auth declarou transferências de recuperação; a apuração precisa classificar cada movimento e verificar a disponibilidade dos ativos.
A Pentesty verificou quem controla os destinos?
Não. A identificação dos destinos é atribuída à Web3Auth, sem investigação própria da cadeia ou garantia de custódia.
O que uma empresa deve pedir antes de retomar a integração?
Escopo das contas, operações reconciliadas, responsabilidades, critérios de retomada e evidências de testes autorizados, com pendências registradas.
Fontes e referências
- Keplr: escopo e orientação aos usuários, 7 de novembro de 2026
- Web3Auth: incidente na infraestrutura, 7 de novembro de 2026
- Web3Auth: operação declarada de recuperação, 7 de novembro de 2026
- Web3Auth: transferências para recuperação, 8 de novembro de 2026
- Web3Auth: identificação dos destinos de recuperação, 8 de novembro de 2026
- Web3Auth: atualizações e prevenção de falsos pedidos, 8 de novembro de 2026
Análise original da Pentesty, publicada em 9 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.