La seguridad de los activos digitales no depende únicamente de la robustez de una clave privada o de la arquitectura de un chip seguro. El caso reciente de Trezor, el fabricante de hardware wallets, pone de relieve un eslabón crítico y a menudo ignorado en la estrategia de ciberseguridad de cualquier empresa: la cadena de suministro. Una brecha en el proveedor de envíos ShipMonk ha dejado al descubierto la información personal de miles de usuarios, transformando una herramienta de seguridad digital en un posible mapa para el crimen físico.

La magnitud de la brecha y el factor tiempo

Lo que comenzó como un incidente contenido se ha convertido en una crisis de confianza sobre la gestión de datos. Inicialmente, Trezor informó que la filtración afectaba a 13.689 clientes, principalmente de Estados Unidos, Reino Unido, Suecia, Colombia, Brasil, Italia y Portugal. Sin embargo, una actualización posterior reveló una cifra mucho más alarmante: otros 67.000 clientes estadounidenses fueron impactados. En total, más de 80.000 usuarios han visto sus datos comprometidos.

El aspecto más controvertido de esta noticia no es solo la intrusión, sino la persistencia de los datos. Los nuevos afectados realizaron sus pedidos entre noviembre de 2019 y agosto de 2021. Esto significa que ShipMonk conservó información sensible durante años, ignorando las políticas de retención de datos. Trezor ha manifestado su profunda decepción, asegurando que solicitaron repetidamente la eliminación de dicha información y que recibieron garantías por escrito de que el proveedor había cumplido con sus obligaciones contractuales.

Un fallo crítico en la infraestructura de terceros

El vector de ataque no fue el software de Trezor ni sus dispositivos, sino una vulnerabilidad en una herramienta externa. El acceso no autorizado fue posible gracias a la explotación de un fallo de día cero identificado como CVE-2026-72898. Se trata de una vulnerabilidad crítica de inyección SQL en Metabase, una plataforma de análisis de datos utilizada por ShipMonk. Con una puntuación CVSS de 10.0, el fallo permitió a los atacantes penetrar en los sistemas y extraer bases de datos de clientes.

Según informes de la firma de seguridad Holborn, el grupo de extorsión ShinyHunters sería el responsable detrás de este ataque. Este incidente subraya cómo una empresa puede tener una seguridad interna impecable, pero quedar expuesta por el uso de un software de terceros que presenta una vulnerabilidad crítica no parcheada.

Datos expuestos y el peligro del phishing físico

Es fundamental diferenciar qué se ha perdido y qué permanece seguro. Trezor ha sido enfática: las claves privadas, las frases semilla (seed phrases), las copias de seguridad y la integridad del firmware de los dispositivos no han sido comprometidas. El dinero de los usuarios sigue estando seguro en la blockchain.

Sin embargo, la información filtrada es extremadamente valiosa para los ciberdelincuentes. Los datos expuestos incluyen:

Nombres completos, direcciones de correo electrónico, números de teléfono, direcciones de envío y números de pedido.

Este conjunto de datos permite realizar lo que algunos expertos denominan phishing en el mundo real. Saber que una persona específica posee un hardware wallet y conocer su dirección física abre la puerta a tácticas de ingeniería social avanzadas. Los atacantes ya no se limitan a enviar correos electrónicos genéricos; ahora pueden enviar cartas físicas fraudulentas, suplantar la identidad de mensajeros o incluso intentar abordajes presenciales, utilizando la urgencia y el miedo para intentar que el usuario revele su frase de recuperación.

La política de los 90 días frente a la realidad

Trezor implementó una política de almacenamiento de datos de 90 días en su eShop, argumentando que es el periodo mínimo necesario para cubrir la entrega, las devoluciones y los reemplazos. Una vez transcurrido este plazo, la empresa procede a eliminar o anonimizar los datos. El problema radica en que esta política solo es efectiva si el socio logístico la ejecuta.

La discrepancia entre la política declarada por Trezor y la ejecución real de ShipMonk evidencia un vacío en la auditoría de terceros. Para los emprendedores y gestores de IT, esto deja una lección clara: las garantías por escrito no sustituyen a las auditorías técnicas independientes sobre la eliminación real de los datos en los servidores del proveedor.

Medidas de mitigación para los usuarios

Trezor ha notificado directamente a los clientes afectados. Para aquellos que han recibido el aviso, la recomendación es extremar la vigilancia ante cualquier comunicación no solicitada. La empresa recuerda que nunca, bajo ninguna circunstancia, se debe introducir la frase de recuperación en un sitio web ni compartirla con supuestos agentes de soporte técnico.

La verificación de cualquier comunicación debe hacerse exclusivamente a través de los canales oficiales marcados en los marcadores del navegador o mediante el correo help@trezor.io. El riesgo actual no es un hackeo técnico del dispositivo, sino la manipulación psicológica del propietario basada en datos reales.

Implicaciones para el ecosistema empresarial en España

Para las empresas españolas, especialmente aquellas integradas en la agenda digital y que operan con flujos de datos internacionales, este caso es un recordatorio crítico sobre la responsabilidad proactiva. Bajo el marco del RGPD y la creciente implementación del AI Act, la gestión de proveedores ya no puede ser un trámite administrativo, sino una función de seguridad operativa.

El tejido empresarial español, compuesto mayoritariamente por PYMES que dependen de servicios de logística y análisis en la nube, debe entender que la responsabilidad legal sobre los datos del cliente permanece, en gran medida, con el responsable del tratamiento. Si un proveedor logístico falla en borrar los datos, la sanción y el daño reputacional recaen primero sobre la empresa que capturó esos datos.

En el contexto de la digitalización acelerada en España, es imperativo que las empresas adopten protocolos de verificación de borrado de datos. No basta con un contrato que diga que los datos serán eliminados; es necesario exigir certificaciones de borrado o implementar sistemas de tokenización donde el proveedor logístico nunca llegue a manejar la identidad completa del cliente, sino solo la información estrictamente necesaria para el envío, minimizando así la superficie de ataque en caso de una brecha similar a la de ShipMonk.

Preguntas frecuentes

Fuentes: Thehackernews, Yahoo, Breachhistory ·