Ledger corrige falha no app de Ethereum que podia levar a assinaturas de transações divergentes

Quem usa uma carteira Ledger para guardar Ether ou tokens ERC20 deve abrir o Ledger Live e verificar a versão instalada do app de Ethereum no dispositivo. Versões anteriores à 1.22.2 não incluem uma correção de segurança. A atualização fecha uma brecha que atingia o principal motivo de existir de uma hardware wallet: a confiança de que a tela mostra exatamente o que será assinado. O caso veio a público em 24 de agosto de 2026, quando a empresa de segurança TestMachine divulgou sua análise. A correção, segundo os relatos disponíveis, já existia nessa data. Entre a descoberta e a divulgação, formou-se uma disputa sobre quem identificou o problema primeiro e quando a Ledger entregou a correção. Para o usuário, o ponto central é outro: qual versão está no seu aparelho e quais permissões (approvals) você concedeu no passado. O que aconteceu, na prática A falha não afetou o firmware do dispositivo nem expôs a chave privada. O problema estava no app de Ethereum instalado na Ledger (o software específico para Ether e tokens ERC20), responsável por montar a transação, exibir os dados na tela e coletar a confirmação. Na versão vulnerável, essa sequência podia ser desordenada. Uma aplicação web maliciosa, com acesso ao dispositivo conectado, conseguiria disparar um segundo comando de assinatura enquanto a primeira transação ainda estava na tela aguardando revisão. O app então trocaria os dados em memória sem apresentar uma nova tela de revisão. O usuário continuaria vendo na tela uma transferência aparentemente inofensiva, mas a confirmação poderia valer para os dados substituídos. Segundo os pesquisadores, o comportamento foi reproduzido em um Ledger Flex. Como os aparelhos compartilham em grande parte o mesmo código do app de Ethereum, Nano X, Nano S Plus, Stax e Apex também são considerados potencialmente afetados. A Ledger não informou qual versão passou a conter o erro; a comparação dos pesquisadores parte da 1.22.1, versão marcada em 27 de maio de 2026. "Clear signing": por que a tela é a promessa central "Clear signing" é a exibição, em texto legível, dos dados completos da transação na tela da hardware wallet antes da confirmação: endereço de destino, valor e, em chamadas de contrato, a ação que o contrato executará. É esse mecanismo que permite desconfiar do computador e do navegador. Mesmo que o site seja falso ou a interface no PC esteja adulterada, a tela do dispositivo deveria mostrar os dados reais antes do clique final. Nesta falha, a chave continuou protegida e o firmware não foi alterado, mas a confirmação podia acabar vinculada a algo diferente do que foi lido. Se a tela deixa de ser um registro confiável do que será assinado, o ganho de segurança em relação a uma carteira de software em máquina comprometida diminui justamente no ponto mais crítico. O núcleo técnico: race condition e comandos APDU O problema é descrito como uma "race condition": um bug em que o resultado depende de qual comando, entre dois quase simultâneos, é processado primeiro. Esse tipo de falha costuma ser difícil de detectar porque, na maior parte do tempo, tudo parece funcionar normalmente; ela aparece quando alguém manipula deliberadamente a ordem. APDU é o formato de comando usado por smart cards e hardware wallets para se comunicar com o computador. Cada assinatura envolve uma sequência de comandos desse tipo. O app de Ethereum mantinha um estado interno indicando qual transação estava em revisão, e esse estado podia ser sobrescrito enquanto a revisão ainda ocorria. Por que um site consegue falar com o dispositivo: WebHID O WebHID é uma interface do navegador que permite a um site conversar diretamente com um dispositivo USB, desde que o usuário conceda permissão explícita. Sem isso, usar uma hardware wallet dentro de aplicações descentralizadas seria pouco prático. Com isso, muitos usuários acabam permitindo um nível de acesso maior do que imaginam. O ataque descrito exige que o usuário já tenha concedido esse acesso a um site manipulado ou sequestrado e inicie uma transação ali. Não é um ataque remoto contra um dispositivo guardado e desconectado. Ainda assim, afeta especialmente quem usa com frequência DEXs, bridges e interfaces de staking. Por que o maior risco costuma estar em approvals ilimitados Em trocas desse tipo, o dano raramente vem de uma transferência pontual. O alvo mais valioso é substituir a operação por um "token approval": a autorização para que um contrato gaste seus tokens no futuro, sem pedir nova confirmação a cada débito. Muitos aplicativos pedem approvals ilimitados por conveniência. Uma vez concedidos, não expiram; só deixam de valer quando o usuário revoga. A diferença prática é direta: - Transferência: você perde exatamente o valor confirmado. - Approval ilimitado: no pior cenário, pode permitir a drenagem de todo o saldo do token quando o destinatário escolher. Atualização para 1.22.2 no Ledger Live A versão 1.22.2 fecha o vetor descrito com dois bloqueios: o app passa a recusar uma nova sessão de assinatura enquanto uma revisão está em andamento e rejeita uma confirmação recebida quando o estado interno não corresponde ao que foi exibido. A atualização é feita pelo Ledger Live: conecte o dispositivo, abra o gerenciador de aplicativos instalados e atualize o app de Ethereum. Saldos não são afetados, porque as chaves derivam da sua recovery phrase e não ficam "dentro" do app. Remover e reinstalar o app também não altera os fundos. Como conferir a versão correta No gerenciador do Ledger Live, cada aplicativo mostra seu número de versão. Se o app de Ethereum estiver em 1.22.2 ou superior, a correção está aplicada. Se estiver em 1.22.1 ou inferior, falta atualizar. Verificar apenas a versão do Ledger Live não resolve. Por que atualizar o firmware não atualiza o app de Ethereum Firmware, Ledger Live e os apps de moedas são mantidos e atualizados separadamente. É comum o usuário atualizar o firmware, achar que está protegido e continuar com o app de Ethereum desatualizado. Essa separação também explica por que incidentes de segurança podem envolver camadas diferentes: em alguns casos o problema é no firmware; aqui, foi em um app substituível, o que dispensa gerar uma nova recovery phrase. Segundo passo: revisar e revogar approvals antigos A atualização protege assinaturas futuras, mas não desfaz permissões já concedidas. Se você interagiu com dApps nos últimos meses, vale checar quais contratos ainda têm autorização para movimentar seus tokens. Exploradores de blocos e interfaces especializadas listam approvals por endereço e por token. Permissões para contratos que você não usa mais podem ser revogadas individualmente. Revogar é uma transação comum e cobra taxa de rede, o que torna o processo mais barato em períodos de menor congestionamento. Há um efeito colateral relevante: cada revogação aparece no histórico e gera custos. Para quem organiza documentação e impostos, registrar essas movimentações durante o processo tende a ser mais simples do que reconstruir tudo depois; ferramentas de imposto e portfólio geralmente importam esses eventos automaticamente. Divergência sobre a divulgação: Ledger x TestMachine As duas partes descrevem a cronologia de forma diferente, e os relatos não foram confirmados de maneira independente. O CTO da Ledger, Charles Guillemet, afirmou que o laboratório interno Ledger Donjon encontrou o erro e que a correção teria sido distribuída cerca de duas semanas antes da publicação. Segundo ele, a TestMachine teria procurado o programa de bug bounty apenas depois, e as declarações da empresa de segurança estariam gerando medo para atrair atenção. A TestMachine diz que seu sistema de testes automatizados, chamado Azimuth, identificou a fraqueza em um Ledger Flex e que os resultados foram compartilhados com a Ledger. Na visão da empresa, no momento da publicação não havia correção disponível. Os dados verificáveis ficam no meio: o changelog da versão 1.22.2 traz a data de 12 de agosto de 2026, e o "tag" assinado no repositório de código, 13 de agosto. A versão só teria aparecido como release publicado por volta de 24 de agosto, na mesma época em que saiu a análise da TestMachine. Quem tentou checar publicamente antes teria dificuldade em encontrar a correção. Houve perdas? O que se sabe até agora Com base nas informações divulgadas até o momento, não há caso confirmado de exploração bem-sucedida. Não há perdas documentadas, e esse caminho não permitiria extrair chaves privadas. Ainda assim, existe uma ressalva importante: uma assinatura obtida dessa forma pareceria on-chain como qualquer assinatura voluntária. O usuário poderia só perceber o problema quando tokens fossem movimentados mais tarde e atribuir o episódio a phishing comum. A ausência de casos confirmados não prova que não houve casos. O que este episódio indica sobre hardware wallets e autocustódia O caso não sustenta a conclusão de que hardware wallets "não prestam". O ataque exigia acesso já concedido ao dispositivo e uma aplicação maliciosa, não tocou na chave privada e foi corrigido. A lição prática é que a segurança da autocustódia exige manutenção contínua. Uma hardware wallet concentra confiança em um dispositivo com tela própria, mas essa segurança depende de firmware, aplicativos e software de acompanhamento, atualizados separadamente. Manter apps em dia, revisar approvals com regularidade e, para valores maiores, adicionar camadas extras de confirmação fazem parte do processo. O que fazer agora 1) Confira e atualize o app de Ethereum. No Ledger Live, verifique o app no dispositivo. Abaixo de 1.22.2, atualize. Atualizar só o firmware não basta. 2) Faça a limpeza de approvals. Verifique quais contratos têm permissão para gastar seus tokens e revogue os que não forem necessários. 3) Registre as movimentações. Revogações e realocações geram taxas e entram no histórico; documente enquanto executa. (Atualizado em 25 de agosto de 2026. Este material não é recomendação de investimento. Preços e estruturas de taxas mudam; verifique as condições com o fornecedor antes de contratar ou comprar.)