En el mundo de la ciberseguridad, existe un principio básico: “La confianza es una vulnerabilidad” y durante años, los usuarios de Linux —especialmente aquellos con distribuciones basadas en Ubuntu— han operado bajo la premisa de que los repositorios oficiales son santuarios digitales, algo que hoy por hoy ha quedado demostrado que no es así.
Y es que, una serie de ataques sofisticados detectados este mes por empresas de seguridad como la firma SlowMist “23pds (山哥)” y expertos como Alan Pope han hecho añicos esa ilusión, revelando que el “core” del problema no es un error de código o un desbordamiento de memoria; sino que es un fallo sistémico en la gestión de la identidad y la confianza dentro de la Snap Store de Canonical.
El epicentro del desastre reside en una técnica de ingeniería social, denominada “Domain Squatting” de Recuperación, que a diferencia de los ataques tradicionales de la cadena de suministro, donde los hackers infiltran malware en el código fuente de un desarrollador (como ocurrió en el famoso caso de SolarWinds), aunque en este caso el atacante ni siquiera necesita tocar la computadora del desarrollador original.
El proceso es quirúrgicamente sencillo para los atacantes, ya que como primer paso realizan una identificación de presas, monitoreando la Snap Store en busca de aplicaciones que no han sido actualizadas en 18 o 24 meses, pero que mantienen una base de usuarios activa.
Luego los atacantes se encargan de cazar dominios que hayan expirado, verificando el dominio de correo electrónico asociado a la cuenta del desarrollador, algo que suele suceder debido al abandono o simple descuido financiero, haciendo que muchos de estos dominios expiren.
Linux用户注意：Snap Store爆发新型攻击，过期域名变黑客后门盗取用户加密资产。
篡改的应用伪装成 Exodus、Ledger Live 或 Trust Wallet 等知名加密钱包，诱导用户输入“钱包恢复助记词”，导致资金被盗。https://t.co/PaHiXCbfUU— 23pds (山哥) (@im23pds) January 21, 2026
Posteriormente, se lleva a cabo la usurpación de Identidad, cuando los atacantes registran el dominio expirado por menos de 15 dólares y una vez que tienen el control del dominio, recrean la cuenta de correo electrónico original.
Una vez que los atacantes tienen el mismo correo electrónico asociado a la aplicación de Snap, solicitan un restablecimiento de contraseña en el portal de Snapcraft. Tras este paso en segundos, el atacante tiene las llaves del reino, una cuenta de editor con “reputación” histórica y miles, cientos de miles y hasta millones de instalaciones activas dependiendo del programa.
Lo que hace que este ataque sea particularmente devastador es el diseño mismo de los paquetes Snap, que a diferencia de los archivos .deb tradicionales o los Flatpaks (donde el usuario suele tener más control sobre cuándo y cómo actualizar), los Snaps están diseñados para actualizarse automáticamente en segundo plano en los ordenadores Linux.
Cuando el atacante toma el control de la cuenta, sube una “actualización” maliciosa, que para el sistema operativo del usuario, esta es una transacción legítima proveniente de un editor confiable, pero que en realidad está descargando e instalando un malware sin intervención humana.
En los casos confirmados recientemente, los atacantes inyectaron código que clonó las interfaces de Wallets de criptomonedas populares como Exodus, Ledger Live y Trust Wallet, haciendo que estas aplicaciones “espejo” sean indistinguibles de las originales.
Su única función es esperar a que el usuario abra la aplicación para presentarle un mensaje de error falso que solicita la “re-sincronización de la frase semilla” y una vez que el usuario introduce sus 12 o 24 palabras mnemotécnicas, los activos digitales son drenados en cuestión de segundos por los ciberdelincuentes.
La crítica más feroz de la comunidad de código abierto, liderada por figuras como Pope que es ex-desarrollador de Canonical, se centra en la respuesta de la empresa. En 2024, tras incidentes menores, Canonical prometió revisiones manuales para los Snaps, sin embargo, este ataque reveló un agujero negro en su política de seguridad que radica en “la confianza heredada”.
El sistema de revisión de la Snap Store parece priorizar la inspección de nuevos editores, pero otorga un “pase libre” relativo a las actualizaciones de editores que ya han establecido una trayectoria, por lo que los atacantes que explotaron precisamente esta brecha, al utilizar cuentas antiguas, evitaron los filtros de seguridad más estrictos que se aplican a los recién llegados.
Además, la latencia en la eliminación de los paquetes maliciosos ha sido alarmante ya que según los reportes de SlowMist, una vez que se denunciaba una aplicación comprometida, el proceso de eliminación por parte de Canonical tomaba días, un tiempo suficiente para que los atacantes recolectaran frases semilla de cientos de usuarios desprevenidos.
Este incidente marca un cambio de paradigma en las amenazas de 2026, porque los atacantes han comprendido que es mucho más rentable atacar la infraestructura de distribución que el software per sé. Sin embargo, Pope está ayudando a revelar los programas potencialmente dañinos, con su Web SnapScope que ahora identifica posibles problemas de seguridad y paquetes sospechosos.
Los ataques a la cadena de suministro son la última frontera de ataques para los cibercriminales, ya que en este caso, al comprometer dominios vencidos de los desarrolladores, los atacantes no solo les robaron dinero a los usuarios; sino que robaron la reputación cómo desarrolladores legítimos y sembraron la duda sobre la plataforma de canonical.
No obstante, la presión sobre Canonical ha llegado a un punto de ebullición, en el cual los usuarios y otros desarrolladores están exigiendo medidas que, para muchos, debieron implementarse hace años, cómo Autenticación de Dos Factores (2FA) Obligatoria, para impedir que ningún editor pueda poder subir una actualización sin una verificación de segundo factor, independientemente de su antigüedad.
También se exige Verificación de Vitalidad de Dominio, a través de un sistema que alerte a la tienda cuando el dominio de un editor está a punto de expirar o ha cambiado de manos recientemente.
Del mismo modo, se exige que las Firmas de Código Basadas en Identidad Real, deban pasar de un modelo de “quien tenga el correo tiene la app” a un modelo de identidad digital verificada para mitigar las fallas que ocasionaron esta campaña de ataques a los usuarios de Linux en Ubuntu.
Para el usuario de a pie, especialmente aquellos con distribuciones como Linux Mint o Suse entre otras, que han optado por bloquear la Snap Store, este evento valida su cautela, porque la descentralización y el control sobre las actualizaciones no deben ser vistas solo cómo preferencias ideológicas; sino cómo mecanismos de defensa activa.
La lección de este jueves negro para la Snap Store de Canonical es comprender que en la era de la sofisticación del cibercrimen, la longevidad de un editor no garantiza su integridad y que la frase semilla es el último bastión de seguridad, y ninguna aplicación, por muy “oficial” que parezca en su canal de actualización, tiene el derecho de solicitarla.
La cadena de confianza se ha roto, y ahora le toca a Canonical reconstruir los eslabones antes de que el ecosistema Snap se convierta en un desierto de usuarios que prefieren la seguridad de lo tradicional sobre la conveniencia de lo automatizado.