La investigadora Erica Windisch, de Cyberdione Labs, publicó el 25 de octubre de 2026 un reporte con 11 fallas en Tailscale, entre ellas tres de severidad alta en Tailscale SSH: desde un equipo ya comprometido, un atacante puede llegar a root en otros servidores de la red. El reporte se llama Tailworm.
Al momento de publicar esta nota no hay parche, ni CVE, ni boletín oficial para estas fallas en la página de boletines de seguridad de Tailscale. La mitigación disponible es de configuración: ajustar las reglas de SSH y apagar el reenvío de puertos donde no haga falta.
Qué es Tailscale SSH
Tailscale arma una red privada entre los equipos de una organización (una «tailnet») sobre WireGuard, sin abrir puertos a internet. Quién puede hablar con quién se define en reglas de acceso centralizadas, las ACL.
Tailscale SSH es una función que reemplaza las claves SSH tradicionales: el servicio tailscaled de cada servidor recibe la conexión y decide, según esas reglas, quién puede entrar y con qué usuario. Para hacerlo, tailscaled corre como root.
El reenvío de puertos (port forwarding) es la opción de SSH que permite usar la conexión como túnel hacia otros servicios del servidor, con ssh -L o ssh -R. Ahí está el problema.
Cómo funciona el ataque
Las tres fallas altas (1 a 3 del reporte) están en el reenvío de unix sockets, los archivos especiales que usan los servicios de un servidor Linux para comunicarse entre sí. Varios de esos sockets solo los puede usar root, porque quien los controla controla el servicio.
- Falla 1: con
ssh -L, el proceso de Tailscale (que es root) se conecta a un socket restringido a root en nombre del atacante. Según el reporte, no hace falta sudo, ni pertenecer al grupo de Docker. - Falla 2: con
ssh -R, el mismo proceso borra un socket de root y pone en su lugar uno del atacante, que pasa a recibir lo que otros servicios le mandan. - Falla 3: una condición de carrera (TOCTOU: el sistema chequea una ruta y la usa un instante después, y en ese medio el atacante la cambia) saltea la lista de rutas permitidas.
Según la cobertura de The Hacker News, en el laboratorio la cadena terminó en ejecución como root en el servidor destino, lectura del archivo de contraseñas del sistema y captura de una clave de alta de equipos, con la que se sumó una máquina del atacante a la red como servidor de confianza. Ese último paso solo funcionó donde no estaba activado Tailnet Lock.
Qué necesita el atacante
No alcanza con estar en internet. Hacen falta dos condiciones:
- Controlar ya un equipo de la tailnet (por una aplicación web vulnerable, un paquete envenenado, phishing o credenciales robadas).
- Que las reglas de SSH le permitan a ese equipo conectarse al servidor destino con el reenvío habilitado.
Windisch probó Tailscale 1.104.2 y headscale 0.29.5 (la implementación abierta del servidor de control) entre el 22 y el 24 de octubre, en laboratorio. Ella describe el ataque como «wormable», capaz de saltar de servidor en servidor, pero eso se midió solo en el laboratorio y otros investigadores discuten la etiqueta.
Lo que frenó la propagación en sus pruebas: reglas por par (un origen, un destino) en lugar de reglas amplias por usuario o etiqueta, y claves de dispositivo atadas a hardware (TPM o Secure Enclave).
Qué dice Tailscale
Según The Hacker News, Mike Shaver, VP de Ingeniería de Tailscale, escribió en Reddit que recibieron el reporte, que ya venían revisando esas mismas áreas con especialistas externos y que encontraron problemas que están corrigiendo. También dijo que todavía están determinando qué configuraciones están afectadas y que no recomiendan que todo el mundo apague Tailscale SSH.
La empresa no confirmó los detalles técnicos.
Windisch dice que mandó el reporte y la prueba de concepto al contacto de seguridad de Tailscale días antes de publicar, y lo describe como reportado «pero no coordinado». La prueba de concepto no es pública.
Qué hacer ahora
Estas son las mitigaciones del reporte y de la cobertura, para equipos que usan Tailscale SSH:
- Revisar las reglas de SSH de la política de la tailnet y reemplazar las reglas amplias por usuario o etiqueta por pares concretos de origen y destino.
- Apagar el reenvío de puertos en cada regla que no lo necesite. En el servicio de Tailscale se define por regla.
- En headscale 0.29.5 el reenvío no se puede apagar: el reporte aconseja tratar cada permiso de SSH como si fuera acceso root al destino.
- Activar el vencimiento de claves de nodo y, donde se pueda, Tailnet Lock y claves atadas a TPM o Secure Enclave.
- Sacar los permisos de app connector a los equipos que no los usan y borrar cualquier
tailscale serveque apunte a un unix socket. - Si un equipo se comprometió, borrarlo desde el panel de control: reinstalarlo no revoca las claves que ya se copiaron.
- Dejar las actualizaciones automáticas activadas, para recibir el parche apenas salga.
El reporte aclara que restringir SSH a usuarios sin privilegios ayuda como defensa adicional, pero no corrige estas fallas: el que se conecta al socket es el propio Tailscale, que corre como root.
¿Cuántas reglas de SSH de su tailnet son por par?
Las reglas amplias son cómodas cuando la red es chica y quedan cuando la red crece.
¿Ya revisaron las suyas? Los leemos en los comentarios.
Fuentes
- Cyberdione Labs: Tailworm (reporte de Erica Windisch)
- The Hacker News: Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers
- Tailscale: Security Bulletins
