--- title: "Falha na ShipMonk expõe dados de 67 mil clientes da Trezor sem comprometer as carteiras" author: "Gustavo Ramos O. Klein" date: "2026-09-06 08:45:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/06/falha-na-shipmonk-expoe-dados-de-67-mil-clientes-da-trezor-sem-comprometer-as-carteiras/md" --- ## Resumo - A ShipMonk expôs dados de 67 mil clientes norte-americanos da Trezor em uma violação divulgada em setembro de 2026. - O vazamento inclui nomes, e-mails, telefones, endereços de entrega e números de pedidos feitos entre novembro de 2019 e agosto de 2021. - A Trezor afirma que os dados antigos deveriam ter sido apagados conforme uma política de retenção de 90 dias. - O acesso foi atribuído ao grupo ShinyHunters, que explorou uma vulnerabilidade zero-day de injeção de SQL no Metabase da ShipMonk. - O incidente teve uma primeira fase em agosto, com 13.689 clientes afetados em sete países e pedidos feitos entre maio e agosto de 2026. - A Trezor afirma que seus sistemas próprios e dispositivos de hardware não foram comprometidos. - Clientes afetados foram alertados sobre o risco de phishing e engenharia social e devem acompanhar as notificações enviadas por e-mail. --- Em setembro de 2026, a **Trezor** revelou que uma violação em seu parceiro logístico, a ShipMonk, expôs dados de **67 mil clientes dos Estados Unidos** que realizaram compras entre novembro de 2019 e agosto de 2021. O conjunto inclui nomes, e-mails, telefones, endereços de entrega e números de pedidos, informações suficientes para identificar compradores e relacioná-los a aquisições de dispositivos da marca. A fabricante afirma que seus sistemas próprios e seus dispositivos de hardware continuam seguros, o que separa o vazamento logístico da segurança das carteiras físicas. Para entender o que realmente aconteceu, é preciso acompanhar onde os dados estavam armazenados, por que ainda existiam e como essa exposição pode ser usada em tentativas de fraude. ## O dado que deveria ter sido apagado Na origem do caso está a relação entre a **Trezor** e a ShipMonk, empresa responsável por uma etapa logística dos pedidos. A Trezor confirmou que recebeu, em **10 de agosto de 2026**, a informação de que havia ocorrido acesso não autorizado aos sistemas da ShipMonk. O episódio mostra como uma empresa pode manter os dispositivos protegidos enquanto um fornecedor conectado ao processo de entrega armazena informações dos compradores. A conexão funciona como uma ponte: ela não precisa carregar chaves privadas para transportar dados capazes de revelar quem comprou, onde a encomenda foi entregue e qual foi o número do pedido. É nessa ponte que a investigação encontrou o problema. O ponto mais delicado apareceu quando a Trezor informou que havia solicitado e recebido garantias por escrito de que os registros seriam excluídos conforme uma **política de retenção de 90 dias**. Retenção, nesse contexto, é o período pelo qual o fornecedor deveria manter os dados antes de apagá-los, segundo a regra mencionada pela própria empresa. A descoberta de registros de pedidos realizados entre 2019 e 2021 indica que essas informações permaneceram armazenadas muito além do prazo comunicado. Na prática, uma promessa de descarte que não foi cumprida ampliou a quantidade de pessoas alcançadas pelo incidente e transformou dados antigos em uma nova fonte de risco para os clientes. ## Como a falha atingiu a infraestrutura do fornecedor Além do problema de armazenamento, a origem técnica do acesso também foi identificada. As fontes atribuem o incidente ao grupo de extorsão **ShinyHunters**, que explorou uma vulnerabilidade classificada como **zero-day de injeção de SQL**, identificada pelo código CVE-2026-72898, no software Metabase usado pela ShipMonk. A expressão zero-day indica que a falha foi explorada antes de uma correção conhecida ou disponível, enquanto a injeção de SQL se refere ao tipo de exploração associado a comandos usados por bancos de dados. Para o leitor, o ponto mais importante é a localização do problema: o acesso ocorreu no software utilizado pelo parceiro logístico, não no hardware da Trezor. Essa distinção ajuda a evitar a conclusão errada de que a carteira física foi invadida. O caso também traduz um problema de interoperabilidade que costuma passar despercebido. Para vender e entregar um produto, a fabricante depende de serviços externos que recebem dados do pedido, processam informações de envio e mantêm registros operacionais. Quando essa cadeia funciona, o cliente vê apenas a entrega; quando um fornecedor falha, a exposição pode alcançar pessoas que nunca criaram uma conta diretamente no sistema atacado. A vulnerabilidade no **Metabase da ShipMonk** mostra que a proteção de uma experiência digital depende das conexões que sustentam o serviço, e não apenas do produto que chega à casa do consumidor. É por isso que a segurança precisa acompanhar cada etapa da jornada dos dados. ## Duas fases de exposição, com grupos diferentes Antes da revelação dos 67 mil clientes norte-americanos, a Trezor já havia comunicado uma primeira fase do incidente. O vazamento inicial, notificado em agosto de 2026, alcançou **13.689 clientes** de Estados Unidos, Reino Unido, Suécia, Colômbia, Brasil, Itália e Portugal. Nesse primeiro grupo, os dados estavam relacionados a pedidos feitos entre **10 de maio e 8 de agosto de 2026** e incluíam nomes, telefones, e-mails e, em muitos casos, endereços físicos. A diferença de período é relevante: a primeira exposição envolveu pedidos recentes, enquanto a segunda trouxe registros históricos que deveriam ter sido removidos. A cronologia revela que o mesmo incidente atingiu conjuntos de dados mantidos em momentos distintos. Na segunda fase, divulgada em setembro, a Trezor informou que outros **67 mil clientes dos Estados Unidos** tiveram seus dados expostos. Esses registros estavam associados a compras realizadas entre novembro de 2019 e agosto de 2021, uma janela muito anterior àquela comunicada em agosto. A presença desses dados antigos explica por que a falha de retenção ganhou tanto peso na história: o problema não ficou limitado aos pedidos que ainda estavam em processamento ou dentro do período operacional recente. A exposição alcançou pessoas que poderiam imaginar que uma compra feita anos antes já não deixaria informações disponíveis no fornecedor. Essa diferença entre os dois grupos é essencial para que cada cliente entenda qual notificação pode receber. ## O que os criminosos podem tentar fazer com esses dados Os registros expostos não são descritos como chaves privadas ou credenciais dos dispositivos. As informações citadas pelas fontes são **nomes, e-mails, números de telefone, endereços de entrega e números de pedidos**, além de dados semelhantes no grupo inicial. A Trezor alertou que essa combinação aumenta o risco de phishing e engenharia social, práticas que usam mensagens ou contatos manipulados para convencer a vítima a revelar informações ou realizar uma ação. Um criminoso que conhece o nome do comprador, o endereço associado a uma entrega e a existência de um pedido pode montar uma abordagem mais convincente do que uma mensagem genérica. Por isso, a exposição logística continua relevante mesmo quando a carteira física não foi comprometida. O alerta merece atenção porque usuários de carteiras de hardware podem ser identificados como pessoas interessadas em criptomoedas. A publicação da CoinDesk reforçou que o incidente não comprometeu fundos ou dispositivos, mas chamou atenção para tentativas de **phishing direcionadas a usuários conhecidos por possuir criptomoedas**. O risco descrito não depende de quebrar a proteção do equipamento: ele depende de persuadir o cliente a clicar em um link, responder a um contato ou fornecer algum dado fora do procedimento habitual. A diferença entre invadir o dispositivo e manipular o usuário é justamente o que torna a engenharia social uma ameaça ligada aos dados de contato e aos endereços físicos. A porta de entrada pode ser uma conversa falsa, não uma falha na carteira. ## O que permanece protegido e qual é o próximo passo Do lado da infraestrutura da Trezor, a empresa afirmou que seus **sistemas próprios e dispositivos de hardware permanecem seguros**. A CoinDesk também registrou que os pedidos realizados pela Amazon não foram afetados, porque utilizam um parceiro logístico diferente. Essas informações ajudam a separar três elementos que podem ser confundidos: o banco de dados do fornecedor, o sistema interno da fabricante e o dispositivo usado pelo cliente. A violação informada está associada ao primeiro elemento, enquanto a Trezor nega comprometimento dos dois seguintes. O fato de uma carteira ter sido comprada ou entregue por meio de uma cadeia logística afetada não significa, segundo as informações divulgadas, que o aparelho ou os fundos armazenados nele tenham sido acessados. Para os clientes afetados, o próximo passo informado pela Trezor é a comunicação direta por e-mail, enviada pelo endereço **[email protected]**. A empresa reiterou que o vazamento aumenta o risco de phishing e engenharia social, portanto qualquer contato que use dados reais do pedido deve ser tratado com atenção redobrada. O leitor pode usar a própria origem da mensagem como primeiro filtro e desconfiar de solicitações inesperadas relacionadas a carteiras, entregas ou movimentações de criptomoedas. A questão central fica mais clara quando as camadas são separadas: os dados de logística foram expostos, mas a Trezor afirma que seus sistemas e dispositivos permanecem seguros. Entender essa diferença permite reagir ao risco correto sem confundir um vazamento de informações pessoais com o comprometimento da carteira física.