Trezor eleva la filtración en ShipMonk a más de 80 mil clientes y expone la cadena de custodia de datos
Trezor confirma que ShipMonk almacenó pedidos que juraba haber eliminado; una falla en Metabase (CVE-2026-72898) abrió 67 mil registros adicionales y lleva el total a más de 80 mil.
La Trezor confirmó la semana pasada que la filtración en su operador logístico ShipMonk involucra no solo a los clientes ya notificados en agosto, sino también a 67 mil compradores adicionales en Estados Unidos, elevando el total conocido a más de 80 mil registros expuestos. La empresa checa de billeteras de hardware afirma haber recibido la comunicación de ShipMonk el 2 de septiembre y publicó el nuevo aviso a clientes el 4 de septiembre. El conjunto complementario cubre pedidos procesados entre noviembre de 2019 y agosto de 2021, periodo de una asociación anterior que Trezor creía concluida.
El Metabase se convirtió en puerta de entrada
La invasión se remonta a la explotación de un día cero en Metabase, plataforma de código abierto de business intelligence usada por ShipMonk en una instancia auto-hospedada. La falla, catalogada como CVE-2026-72898, es una inyección de SQL no autenticada con puntaje CVSS 10.0 y permite al atacante consultar toda la base del producto sin credenciales. ShipMonk reportó el acceso indebido el 10 de agosto; Trezor emitió el primer comunicado el 13 de agosto, mencionando 13,689 clientes afectados.
La misma vulnerabilidad afecta a otra víctima corporativa de la misma operación, la corretora de criptomonedas Bits of Gold, lo que sugiere que ShipMonk operaba un único entorno Metabase compartido entre cuentas de clientes. Este detalle importa para el comprador empresarial: cuando el SaaS logístico centraliza el análisis de pedidos de varias marcas en una única instancia, una falla en la capa de BI expone a todas al mismo tiempo, incluso si las marcas no tienen relación comercial entre sí.
No hubo compromiso de las billeteras físicas Trezor, ni de las seed phrases de los clientes, ambas aisladas por diseño fuera del flujo logístico. Los datos exfiltrados son de naturaleza operacional: nombres, correos electrónicos, teléfonos, direcciones de entrega y números de pedido del periodo en que ShipMonk despachaba productos de Trezor.
El punto crítico es la promesa de eliminación
Trezor afirma que solicitó repetidamente a ShipMonk la eliminación de los datos tras el fin de la asociación y recibió confirmación por escrito de que el purgado había ocurrido. Los archivos permanecían en la base. Esta cláusula, común en contratos de tratamiento de datos bajo GDPR y LGPD, fue violada en dos planos: en el deber contractual de destrucción y en el deber de honestidad sobre el cumplimiento. La palabra del proveedor, sin verificación técnica, pasó a valer menos que los pedidos que alegaba haber eliminado.
El caso reabre una discusión que los ejecutivos de datos han estado posponiendo: ¿cómo auditar el cumplimiento de cláusulas de eliminación en proveedores que operan SaaS o servicios físicos, sin paralizar la operación? Pocos contratos prevén una verificación técnica tras la finalización, y menos aún prevén custodia de logs comprobatorios por parte del controlador. El modelo estándar sigue siendo la confianza en la declaración de la contraparte, ahora oficialmente insuficiente para dispositivos que también sufren los llamados ataques de herramienta: agresiones físicas contra dueños de criptoactivos identificados a partir de direcciones residenciales en bases logísticas.
El alcance geográfico y el próximo objetivo
ShipMonk opera centros de distribución para clientes en Estados Unidos, Reino Unido, Suecia, Colombia, Brasil, Italia y Portugal. Esto amplía el alcance de lo que otras marcas que contrataron al mismo proveedor pueden necesitar comunicar a sus propios usuarios, con implicaciones regulatorias distintas en cada jurisdicción. La ANPD, en Brasil, exige notificación a los titulares en incidentes que produzcan riesgo relevante, y reguladores europeos pueden considerar el incumplimiento en la obligación de eliminación del artículo 17 del GDPR, aplicable al procesador contratado.
Para el CISO de cualquier empresa que despacha bienes a través de un operador logístico tercerizado, tres lecturas se imponen inmediatamente. Primero, saber si el proveedor ejecuta instancias de Metabase auto-hospedadas y, en caso positivo, exigir prueba de la corrección de la CVE-2026-72898 antes del próximo ciclo comercial. Segundo, revisar las cláusulas de retención y eliminación en los contratos vigentes, ajustando la ventana y la mecánica de verificación. Tercero, considerar la rotación criptográfica de identificadores de pedido y el uso de direcciones intermedias en productos sensibles, práctica que la propia Trezor ya ha señalado estar evaluando para nuevos ciclos, y que elimina del proveedor la capacidad de conservar información útil por cuenta propia.
La pregunta de fondo no es técnica. Es de gobernanza contractual: cuando una cadena de custodia depende de lo que el proveedor jura haber hecho, el comprador asume el riesgo integral de la mentira. El caso Trezor obliga al mercado corporativo de logística a discutir si la próxima generación de contratos exige, además de la promesa, algún equivalente de recibo criptográfico que pruebe que los datos realmente salieron de la base.