El informe Tailworm, publicado el 25 de octubre por Erica Windisch de Cyberdione Labs, describe una vulnerabilidad que convierte a Tailscale SSH en una puerta de entrada wormable. Según el documento, un único endpoint ya bajo control del atacante puede esclavizar cualquier otro nodo al que la política de acceso de la malla permita conectarse.
Las pruebas se realizaron en un entorno controlado durante tres días, empleando Tailscale versión 1.104.2 y la variante autogestionada headscale versión 0.29.5. No se atacaron redes reales; la investigación se limitó a reproducir el comportamiento en laboratorio. Hasta la fecha, la empresa no ha emitido un número CVE, ni ha publicado una versión corregida.
Cómo funciona la cadena de explotación
El vector de ataque parte de dos premisas: la activación de port forwarding en Tailscale SSH y el control previo de un dispositivo que, según las reglas de acceso, tenga permiso para comunicarse con el objetivo. A diferencia de un servidor SSH tradicional, el mecanismo de Tailscale SSH no valida contraseñas ni claves públicas; identifica al equipo mediante su node-key y decide la conexión mediante una única regla de autorización.
Con esa lógica, el atacante solo necesita un foothold inicial –que puede obtener mediante una aplicación web vulnerable, un paquete contaminado, phishing o credenciales robadas– para lanzar la cadena de escalada sin necesidad de robar claves o contraseñas adicionales.
Métodos probados en el laboratorio
Conexión a socket privilegiado mediante port forwarding
En la primera demostración, una sesión SSH normal con reenvío de puertos provocó que el proceso tailscaled (que se ejecuta con privilegios de root) estableciera una conexión a un socket del sistema accesible solo para root. En cuestión de segundos, el investigador obtuvo el contenido del archivo /etc/shadow, logrando leer contraseñas en texto cifrado sin elevar privilegios de forma explícita.
Sustitución de socket para ejecución directa
El segundo método consistió en remplazar el socket original, de propiedad de root, por uno controlado por el atacante. De este modo, cualquier comando enviado a través del túnel se ejecutaba con privilegios de root contra los servicios vinculados al socket, ofreciendo una vía de ejecución remota inmediata.
Condición de carrera para capturar la clave de enrolamiento
La tercera prueba aprovechó una condición de carrera en la verificación de rutas de archivo del reenvío. Al intercalar la comprobación y el uso del camino, el investigador interceptó la clave usada para enrolar nuevos dispositivos en la malla. Con esa clave, fue posible añadir una máquina del atacante como servidor de confianza, expandiendo el control a toda la red.
Este último paso sólo logró completarse en entornos donde la función Tailnet Lock estaba desactivada; cuando estaba habilitada, la clave se capturó en tránsito pero el atacante no pudo registrar el nuevo nodo.
Respuesta de Tailscale y recomendaciones inmediatas
Tras recibir el informe, Mike Shaver, vicepresidente de ingeniería de Tailscale, confirmó en Reddit que el equipo ya estaba investigando las áreas señaladas y que trabajaba con auditorías externas. La compañía aún no había decidido qué configuraciones estaban afectadas y no recomendó desactivar Tailscale SSH de forma general.
En la práctica, el grado de mitigación depende del tipo de despliegue. En el servicio alojado por Tailscale, el reenvío de puertos puede desactivarse por regla individual; en headscale 0.29.5 esa opción no existe, por lo que cada autorización SSH debe considerarse como concesión de root al destino.
El informe también señala dos factores que limitaron la propagación: reglas de acceso estrictas definidas como pares origen-destino y el uso de claves vinculadas a hardware (TPM o Secure Enclave). La comunidad de investigadores ha debatido si la descripción «wormable» es exagerada, aunque la mayoría coincide en que la capacidad de escalar privilegios sin interacción humana es grave.
Otros hallazgos y contexto histórico
Además del vector SSH, Tailworm incluye diez vulnerabilidades adicionales, entre ellas un fallo en los app connectors (funcionalidad experimental «conn25») que permite a usuarios autorizados enviar tráfico a destinos no aprobados, como el servicio de metadatos de proveedores cloud, y debilidades en el relay DERP que facilitan la intercepción de datos entre nodos.
Es importante recordar que, a principios de 2026, Tailscale ya había corregido varios problemas de manejo de sockets y de SSH en la versión 1.98.9, lo que muestra una trayectoria de parches continuos. Sin embargo, la ausencia de un CVE y de una versión corregida para la vulnerabilidad descrita mantiene el riesgo latente hasta que se publique una solución oficial.
Mientras tanto, los administradores deben revisar sus reglas de acceso SSH, restringir el reenvío de puertos cuando sea posible, eliminar permisos de app connector innecesarios, revocar claves de dispositivos comprometidos desde el plano de control y habilitar la expiración automática de node-keys. Estas acciones, aunque no eliminan la vulnerabilidad subyacente, reducen considerablemente la superficie de ataque.
