A Ledger corrigiu silenciosamente uma falha grave em seu aplicativo Ethereum quase duas semanas antes de qualquer pessoa fora da empresa saber que ela existia, e a forma como essa linha do tempo veio à tona se transformou em sua própria pequena controvérsia. A vulnerabilidade do Ledger Ethereum envolvia uma condição de corrida que poderia permitir que um aplicativo malicioso trocasse uma transação legítima por uma maliciosa enquanto o usuário ainda a estava aprovando na tela do dispositivo. A Ledger corrigiu o problema em 12 de agosto de 2026, mas quase não disse nada publicamente até que um pesquisador de segurança forçou a divulgação da história mais de uma semana depois.
Summary
Principais pontos
- A Ledger corrigiu a falha em seu aplicativo Ethereum em 12 de agosto de 2026, disponibilizando a correção na versão 1.22.2 sem um boletim público de segurança.
- O bug era uma condição de corrida envolvendo comandos APDU que poderia permitir que um aplicativo malicioso trocasse uma transação legítima durante o clear signing.
- A equipe interna da Ledger, Donjon, encontrou a falha usando ferramentas assistidas por IA antes que qualquer pesquisador externo a relatasse.
- A empresa de segurança TestMachine divulgou publicamente o bug entre 21 e 23 de agosto de 2026, usando um agente de IA chamado Azimuth.
- Até 24 de agosto de 2026, não haviam surgido relatos confirmados de fundos roubados ligados à falha.
Correção secreta da Ledger para vulnerabilidade no aplicativo Ethereum
A correção da Ledger chegou sem alarde em 12 de agosto de 2026, escondida em uma atualização de software de rotina em vez de sinalizada como um patch de segurança. A alteração foi incluída na versão 1.22.2 do aplicativo Ethereum e, por cerca de dez dias, a empresa não emitiu nenhum aviso, nenhum post no blog e nenhuma declaração pública explicando o que havia sido efetivamente corrigido.
Detalhes do patch e da versão
Os usuários que executavam o aplicativo Ethereum precisavam atualizar para a versão 1.22.2 ou posterior para receber a correção. A Ledger enfatizou que atualizar apenas o software complementar para desktop ou mobile não seria suficiente, já que o código vulnerável estava no aplicativo em execução diretamente no próprio dispositivo de hardware.
Natureza do bug de condição de corrida
A falha girava em torno de comandos APDU, a linguagem técnica que os dispositivos Ledger usam para se comunicar entre um computador conectado e o chip seguro que realmente assina as transações. A promessa central de segurança da Ledger se baseia no que a empresa chama de clear signing, em que a tela do dispositivo exibe detalhes legíveis da transação para que os usuários saibam exatamente o que estão aprovando antes de confirmar.
A condição de corrida minava essa promessa. Durante fluxos de clear signing, um comando malicioso concorrente poderia se infiltrar e substituir a transação original por outra diferente antes que o usuário concluísse o processo de aprovação. Na prática, alguém poderia acreditar que estava confirmando uma pequena transferência de tokens enquanto, na verdade, estava autorizando acesso ilimitado a tokens para o endereço de carteira de um invasor.
Linha do tempo de descoberta e divulgação
O intervalo entre o patch silencioso da Ledger e a divulgação pública é onde a história fica contenciosa, com ambos os lados descrevendo uma sequência de eventos diferente.
Detecção interna pela Donjon usando ferramentas de IA
A unidade interna de segurança da Ledger, conhecida como Donjon, afirma ter descoberto a vulnerabilidade por conta própria, antes que qualquer pesquisador externo a sinalizasse. A equipe recorreu a ferramentas de pesquisa assistidas por IA para identificar e corrigir a falha, uma abordagem que reflete uma mudança mais ampla em direção à caça de vulnerabilidades assistida por máquina dentro das equipes de segurança de carteiras de hardware.
Divulgação pública pelo pesquisador de segurança TestMachine
Esse período silencioso terminou quando a TestMachine, uma empresa de segurança em IA, publicou suas próprias descobertas entre 21 e 23 de agosto de 2026. A TestMachine afirma ter descoberto o bug usando um agente autônomo de IA chamado Azimuth, que a empresa desenvolveu especificamente para caçar exploits em contratos inteligentes. No próprio benchmark EVMBench da empresa, o Azimuth supostamente detecta 86,3% dos bugs conhecidos com cerca de 2,7% de falsos positivos.
Em sua divulgação, a TestMachine escreveu que a falha foi “encontrada pelo Azimuth durante uma varredura autônoma do aplicativo Ledger Ethereum”, acrescentando que ela havia sido “validada no Flex”, “compartilhada e verificada com a equipe”, enquanto a empresa estava “recusando qualquer recompensa (bounty)”. A TestMachine também apontou para código APDU e de interface de usuário compartilhado entre o Nano X, Nano S Plus, Stax e Apex, sugerindo que o problema subjacente poderia se estender além do dispositivo Flex que foi testado.
Resposta e contestação da Ledger
O CTO da Ledger, Charles Guillemet, contestou fortemente a forma como a divulgação foi apresentada. Ele disse que a TestMachine só entrou em contato com o programa de recompensas da Ledger depois que a correção já havia sido lançada e que a correção já estava ativa havia cerca de duas semanas quando os pesquisadores tornaram o caso público. Guillemet acusou a TestMachine de fabricar medo para chamar atenção em vez de praticar pesquisa de segurança responsável, argumentando que a narrativa pública dava a entender que o bug ainda estava ativo quando já havia sido resolvido.
O relato da TestMachine difere quanto à sequência. A empresa sustenta que descobriu e validou o bug de forma independente, compartilhou suas descobertas com a Ledger, recusou a oferta de recompensa e então decidiu publicar. O repositório público do aplicativo Ethereum da Ledger mostra várias alterações relacionadas à segurança feitas ao longo de agosto, cobrindo estados de assinatura e finalização de mensagens, embora os registros disponíveis não isolem claramente uma única alteração vinculada especificamente a essa falha.
Impacto na segurança e orientações para usuários
Para os usuários comuns da Ledger, o número mais importante nessa história é simples: até 24 de agosto de 2026, não haviam surgido relatos confirmados de fundos roubados ligados à vulnerabilidade. Isso não significa que o risco fosse apenas teórico. Um exploit funcional poderia permitir que um invasor reescrevesse os termos de uma transação que o usuário acreditava estar aprovando, transformando uma transferência rotineira de tokens em acesso ilimitado para um endereço malicioso.
Na época da publicação, não havia prova de conceito completa demonstrando roubo real de fundos em todos os dispositivos mencionados, e a Ledger não havia divulgado um aviso formal de segurança nem anunciado qualquer processo de compensação ligado ao incidente. Esse silêncio é, por si só, parte da história. Um patch lançado discretamente e sem um boletim público deixa os usuários dependentes de divulgações de terceiros para entender o risco, em vez de receberem essa informação diretamente do fabricante.
A Ledger orientou os usuários a atualizarem tanto o firmware do dispositivo quanto o aplicativo Ethereum para a versão 1.22.2 ou posterior, observando que atualizar apenas o software complementar para desktop ou mobile não substituirá um aplicativo desatualizado na própria carteira de hardware. Dado que a TestMachine apontou código compartilhado entre as linhas Flex, Nano X, Nano S Plus, Stax e Apex, manter todos os dispositivos conectados atualizados continua sendo a salvaguarda mais direta disponível para os usuários neste momento.
Este episódio também reforça por que o método de descoberta importa tanto quanto a própria correção. O uso de ferramentas assistidas por IA pela Donjon para detectar a falha antes de qualquer pessoa de fora mostra como a varredura automatizada está se tornando parte da camada interna de defesa nos fabricantes de carteiras de hardware. Ao mesmo tempo, o uso pela TestMachine de seu próprio agente de IA para encontrar e divulgar de forma independente a mesma classe de bug em poucas semanas levanta uma questão incisiva para o setor: se ferramentas de IA agora conseguem revelar essas falhas tanto de dentro quanto de fora de uma empresa quase simultaneamente, os prazos de divulgação e as práticas de transparência talvez precisem acompanhar o ritmo tão rapidamente quanto as próprias ferramentas.
Perguntas frequentes (FAQ)
Qual foi a falha de segurança no aplicativo Ethereum da Ledger?
Foi uma condição de corrida envolvendo comandos APDU que poderia permitir que um aplicativo malicioso trocasse transações legítimas por transações maliciosas durante a assinatura.
Como e quando a vulnerabilidade foi descoberta pela Ledger?
A equipe interna de segurança da Ledger, Donjon, encontrou a falha usando ferramentas assistidas por IA antes que qualquer pesquisador externo a relatasse.
Quando a vulnerabilidade foi divulgada publicamente?
O pesquisador de segurança TestMachine divulgou publicamente o bug entre 21 e 23 de agosto de 2026.
Há alguma evidência de que fundos foram roubados devido a essa vulnerabilidade?
Até 24 de agosto de 2026, não haviam aparecido relatos confirmados de fundos roubados ligados a essa vulnerabilidade.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Qual foi a falha de segurança no aplicativo Ethereum da Ledger?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Foi uma condição de corrida envolvendo comandos APDU que poderia permitir que um aplicativo malicioso trocasse transações legítimas por transações maliciosas durante a assinatura.”}},{“@type”:”Question”,”name”:”Como e quando a vulnerabilidade foi descoberta pela Ledger?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A equipe interna de segurança da Ledger, Donjon, encontrou a falha usando ferramentas assistidas por IA antes que qualquer pesquisador externo a relatasse.”}},{“@type”:”Question”,”name”:”Quando a vulnerabilidade foi divulgada publicamente?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”O pesquisador de segurança TestMachine divulgou publicamente o bug entre 21 e 23 de agosto de 2026.”}},{“@type”:”Question”,”name”:”Há alguma evidência de que fundos foram roubados devido a essa vulnerabilidade?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Até 24 de agosto de 2026, não haviam aparecido relatos confirmados de fundos roubados ligados a essa vulnerabilidade.”}}]}
Artigo produzido com a assistência de inteligência artificial e revisado pela equipe editorial.
