Un solo dispositivo comprometido dentro de una red Tailscale puede servir para obtener acceso root en otros servidores que esa máquina tenga a su alcance, según un investigador de seguridad que publicó sus hallazgos esta semana. El ataque requiere dos condiciones: que Tailscale SSH esté configurado para permitir el reenvío de puertos y que el atacante ya controle un dispositivo al que las reglas de acceso de la red autoricen a conectarse al objetivo.
Los resultados se publicaron el 25 de octubre en un informe titulado Tailworm, elaborado por Erica Windisch, de Cyberdione Labs. Windisch probó Tailscale versión 1.104.2 y headscale versión 0.29.5 —el servidor autoalojado que algunas redes usan en lugar del servicio gestionado de la empresa— durante tres días en un laboratorio. El informe describe pruebas sobre ese software, no ataques contra redes reales. Hasta la publicación, Tailscale no había emitido ningún boletín de seguridad, ni identificador CVE, ni versión corregida.
Tailscale respondió públicamente. Mike Shaver, vicepresidente de ingeniería de la compañía, escribió en Reddit que Tailscale había recibido el informe, que ya estaba examinando esas mismas áreas con especialistas externos en seguridad y que había encontrado problemas en los que está trabajando para corregirlos. Shaver señaló que la empresa aún está determinando qué configuraciones se ven afectadas y que "no recomienda que todo el mundo desactive Tailscale SSH".
Un modelo de autenticación distinto
Tailscale SSH no funciona como un servidor SSH convencional. En lugar de verificar la contraseña o la clave del usuario que se conecta, identifica el dispositivo, y una única regla de acceso decide si ese dispositivo puede abrir una sesión SSH hacia un objetivo. Por eso el ataque no necesita contraseñas ni claves robadas. Necesita primero un punto de apoyo en un dispositivo, que según el informe un atacante puede obtener por las vías habituales: una aplicación web vulnerable, un paquete de software envenenado, phishing o credenciales de inicio de sesión robadas. Tailscale no crea ese primer punto de apoyo.
Lo que un administrador puede hacer al respecto depende de dónde se ejecute la red. En el servicio gestionado de Tailscale, el reenvío puede desactivarse por regla. En headscale versión 0.29.5, el reenvío no puede desactivarse en absoluto. El informe afirma que, por tanto, toda concesión de SSH allí debe tratarse como si otorgara root en el objetivo.
Pruebas en laboratorio
En el laboratorio, Windisch mostró el problema por etapas. Mediante el reenvío de puertos SSH estándar, una sesión ordinaria hizo que el proceso de Tailscale con nivel root se conectara a un socket del sistema al que solo root debería acceder, y la prueba obtuvo root y leyó el archivo de contraseñas del sistema casi de inmediato, sin privilegios de administrador.
Un segundo método sustituyó un socket propiedad de root por el del atacante, lo que permitió la ejecución directa de comandos como root contra determinados servicios. Un tercer método eludió una comprobación de seguridad destinada a limitar los archivos a los que el reenvío puede acceder, aprovechando una condición de carrera entre el momento en que el sistema verifica una ruta de archivo y el momento en que la utiliza. Según el informe, esa cadena fue más lejos en el laboratorio: capturó una clave empleada para inscribir nuevos dispositivos y la usó para unir una máquina propia del atacante a la red como servidor de confianza.
Ese último paso funcionó de principio a fin solo en redes donde la función Tailnet Lock de Tailscale no estaba habilitada. En las redes que sí la tienen, los secretos necesarios se capturaron en tránsito, pero el paso final no se completó.
Windisch describe el resultado global como "gusano" (wormable). En el laboratorio, un dispositivo comprometido podía propagarse a todos los dispositivos que las reglas de acceso permitían, sin contraseñas, sin claves robadas y sin acción del usuario, en menos de un segundo por paso. En palabras del informe, "la malla convierte un punto de apoyo ordinario en acceso privilegiado para toda la flota a velocidad de máquina". Esa propagación se midió en un laboratorio, no se observó en redes reales.
El informe señala dos elementos que la frenaron: reglas de acceso redactadas como pares individuales de origen a destino, que por sí solas detuvieron la propagación, y claves de dispositivo vinculadas a hardware como un TPM o Secure Enclave. Algunos investigadores que leyeron el informe han cuestionado públicamente la descripción de "gusano", mientras que otros han calificado el hallazgo del acceso root como grave.
Otros hallazgos y dudas
El problema de SSH es uno de los 11 hallazgos del informe, que también abarca los conectores de aplicaciones de Tailscale, su función serve, el relé DERP utilizado entre dispositivos y headscale. Windisch declaró a The Hacker News que la escalada de privilegios en SSH "es preocupante", pero que el hallazgo del conector de aplicaciones "puede ser más impactante para algunas organizaciones". Ese hallazgo, en una función experimental llamada conn25, permite a un usuario autorizado enviar tráfico a destinos que el equipo de seguridad nunca aprobó, incluido el servicio de metadatos de un proveedor de nube, que puede entregar credenciales de servidor.
Todos los hallazgos se basan únicamente en el informe de Windisch. Ningún otro investigador los ha reproducido públicamente y Tailscale no ha confirmado las afirmaciones técnicas concretas. Windisch dijo que el código de prueba de concepto detrás de los hallazgos no es público y que solo lo proporcionó al contacto de seguridad de Tailscale.
Windisch ha descrito la divulgación como "informada pero no coordinada", y lo escribió así en Ycombinator HN, donde al menos un comentarista calificó de irresponsable publicar sin informar antes a Tailscale. En respuesta a las preguntas de The Hacker News, Windisch afirmó que de hecho había entregado a Tailscale una copia del informe y del código de prueba de concepto antes de la publicación pública, enviándolos al contacto de seguridad de la empresa el sábado anterior. Dijo que también había planteado preocupaciones sobre la arquitectura de Tailscale al consejero delegado de la compañía anteriormente, y que había publicado un hash de archivo y aconsejado a los usuarios desactivar Tailscale SSH.
El informe es el último de una serie de problemas en la misma parte de Tailscale. A principios de 2026, la compañía corrigió varias fallas en Tailscale SSH y en el manejo de sockets del servidor, incluida una en la que el reenvío de sockets Unix de SSH podía alcanzar un socket privilegiado, en la versión 1.98.9.
Qué hacer ahora
Como no hay parche, las medidas disponibles consisten en cambios en la configuración de Tailscale SSH y funciones relacionadas. El informe y los consejos de Tailscale coinciden en la mayoría de ellas.
- Revisar las reglas de acceso de Tailscale SSH. Redactarlas como pares individuales de origen a destino que nombren un dispositivo y un objetivo, y eliminar las reglas amplias que conceden acceso por identidad o etiqueta. El informe califica las reglas por pares como el único control que detuvo la propagación en las pruebas.
- Desactivar el reenvío de puertos SSH donde sea posible. En el servicio gestionado de Tailscale es una configuración por regla. En headscale versión 0.29.5 no puede desactivarse, así que debe tratarse toda concesión de SSH como si otorgara root en el objetivo.
- Eliminar los permisos de conector de aplicaciones de los dispositivos que no los necesiten.
- Eliminar cualquier reenvío de tailscale serve que apunte a un socket Unix.
- Activar la expiración de claves de nodo, para que una clave de dispositivo robada no siga siendo válida indefinidamente.
- Si un dispositivo está comprometido, eliminarlo en el plano de control. Reinstalar la máquina no revoca las claves que un atacante pueda haber copiado de ella.
Tailscale también sugiere habilitar el modo de verificación SSH, que añade un paso de inicio de sesión antes de que comience una sesión, y activar las actualizaciones automáticas. El modo de verificación no corrige la escalada de privilegios; solo añade otra barrera delante de ella.
Deja una respuesta