Fallos sin parchear en Tailscale SSH convierten un dispositivo comprometido en root sobre sus vecinos

Una evaluación de laboratorio publicada el 25 de octubre de 2026 describe una cadena de debilidades en Tailscale SSH que, bajo condiciones concretas, permite a un atacante que ya controla un nodo de una tailnet obtener root en todos los demás nodos a los que ese nodo puede llegar. Al momento de escribir esto no hay CVE, ni boletín de seguridad, ni versión corregida, lo que obliga a los equipos de defensa a apoyarse en la configuración en lugar de en los parches.

Qué ocurrió

La evaluación probó Tailscale 1.104.2 y headscale 0.29.5, la alternativa autoalojada al servicio de coordinación de Tailscale, durante tres días en un laboratorio controlado. Solo se trabajó sobre software publicado. No se tocó ninguna red de producción, y el código de prueba de concepto se compartió de forma privada con Tailscale en lugar de publicarse.

El problema central está en cómo Tailscale SSH gestiona el reenvío de puertos. Tailscale SSH no autentica al usuario con contraseña ni clave. Identifica al dispositivo que se conecta y deja que una única regla de acceso decida si ese dispositivo puede abrir una sesión en el destino. Si la regla también permite el reenvío de puertos, se demostraron tres técnicas distintas para escalar una sesión ordinaria a root:

• Reenvío local de socket Unix. El daemon de Tailscale se ejecuta como root. Reenviar un socket Unix a través de él hizo que el daemon se conectara a sockets que solo root debería poder abrir, y la prueba leyó el archivo de contraseñas del sistema casi de inmediato, sin ningún privilegio de administrador.
• Reenvío inverso de socket. Un socket propiedad de root fue sustituido por uno controlado por el atacante, lo que permitió ejecutar comandos como root contra ciertos servicios que confían en ese socket.
• Una condición de carrera time-of-check / time-of-use. Una comprobación de seguridad pensada para limitar las rutas de archivo que el reenvío puede tocar fue derrotada aprovechando el intervalo entre la validación de la ruta y su uso.

En el laboratorio, la tercera técnica fue más lejos. Capturó una clave usada para inscribir nuevos dispositivos y la utilizó para unir una máquina controlada por el atacante a la tailnet como servidor de confianza. Ese último paso solo funcionó de principio a fin en redes sin Tailnet Lock. Donde Tailnet Lock estaba activo, los secretos se capturaron igualmente en tránsito, pero la inscripción falló.

El informe califica el resultado de "wormable": un único dispositivo comprometido podría propagarse a todos los pares que las reglas de acceso permitan, sin contraseñas, sin claves robadas y sin interacción del usuario, en menos de un segundo por salto. Esa afirmación ha recibido críticas públicas de algunos profesionales, mientras que otros consideran que el hallazgo del acceso root es grave por sí solo. Conviene ser precisos. La propagación se demostró en un laboratorio, ningún tercero la ha reproducido y Tailscale no ha confirmado las afirmaciones técnicas concretas.

La cadena SSH es uno de los 11 hallazgos de la misma evaluación. Los demás abarcan los app connectors de Tailscale, la función serve, el relé DERP y headscale. Uno de ellos afecta al modo experimental conn25 de los app connectors, donde un usuario autorizado podría enrutar tráfico hacia destinos que el equipo de seguridad nunca aprobó, incluido el endpoint de metadatos de un proveedor cloud, que entrega credenciales de servidor.

La posición de Tailscale

Tailscale ha respondido públicamente. Su vicepresidente de ingeniería afirmó que la empresa recibió el informe, ya estaba revisando esas mismas áreas de código con especialistas externos y había encontrado problemas que ahora está corrigiendo. La compañía sigue determinando qué configuraciones están afectadas y no recomienda de forma explícita que todo el mundo desactive Tailscale SSH.

La propia divulgación ha sido descrita por su autora como "reportada pero no coordinada". El informe y la prueba de concepto se enviaron al contacto de seguridad de Tailscale antes de la publicación, y se difundió públicamente un hash del archivo junto con el consejo de desactivar Tailscale SSH. No es el primer problema en esta parte del producto. A principios de 2026, Tailscale corrigió varios errores de SSH y de gestión de sockets, incluido uno en el que el reenvío de sockets Unix podía alcanzar un socket privilegiado, en la versión 1.98.9.

Por qué importa

Tailscale suele desplegarse precisamente para sustituir VPN planas por acceso basado en identidad y mínimo privilegio. El punto débil descrito aquí no es el túnel WireGuard, sino el modelo de confianza alrededor de SSH: el dispositivo es la identidad, y el reenvío se ejecuta dentro de un proceso root. Eso significa que el primer punto de apoyo del atacante, obtenido por las vías habituales a través de una aplicación web vulnerable, un paquete envenenado, phishing o credenciales robadas, se convierte en la única parte difícil. Todo lo demás viaja sobre las propias reglas de acceso de la malla.

Dos cosas detuvieron la cadena en las pruebas, y ambas están hoy en manos del administrador:

• Reglas de acceso escritas como pares origen-destino individuales, que nombran un dispositivo y un destino, en lugar de concesiones amplias por identidad de usuario o etiqueta.
• Claves de dispositivo ligadas a hardware como un TPM o Secure Enclave, que no pueden copiarse sin más desde un host comprometido.

Donde el plano de control es autoalojado, el margen es menor. En el servicio gestionado de Tailscale, el reenvío de puertos puede desactivarse por regla. En headscale 0.29.5 no puede desactivarse en absoluto, así que cada concesión SSH allí debería tratarse como equivalente a root en el destino.

Qué hacer ahora

Como no hay parche, las mitigaciones son cambios de configuración. Las recomendaciones de Tailscale y las del informe coinciden en la mayoría:

1. Reescribe las reglas de acceso SSH como pares explícitos. Elimina las reglas amplias que conceden SSH por identidad o etiqueta. Las reglas por par fueron el único control que contuvo la propagación en las pruebas.
2. Desactiva el reenvío de puertos SSH siempre que sea posible. En el servicio gestionado es un ajuste por regla. En headscale 0.29.5 no está disponible, así que asume root en cada concesión.
3. Retira los permisos de app connector de los dispositivos que no los necesitan y revisa cualquier uso del modo experimental conn25.
4. Elimina cualquier reenvío de tailscale serve que apunte a un socket Unix.
5. Activa la caducidad de claves de nodo para que una clave de dispositivo robada no siga siendo válida indefinidamente.
6. Si un dispositivo se ve comprometido, elimínalo en el plano de control. Reinstalar la máquina no revoca las claves que el atacante ya pueda haber copiado.
7. Activa el SSH check mode y las actualizaciones automáticas. El check mode añade un paso de autenticación antes de iniciar la sesión. No corrige la escalada de privilegios, pero es una barrera más delante de ella.

La lección de fondo es que la seguridad de una red mallada es exactamente tan fuerte como el alcance que permiten sus reglas. La suposición de que el movimiento lateral es difícil una vez que un dispositivo está "dentro" de la tailnet no se sostiene aquí. Nuestros servicios de penetration testing se construyen justamente alrededor de esta pregunta: partiendo de un único host que se asume comprometido, ¿hasta dónde puede llegar realmente un atacante a través de tus reglas de acceso, ajustes de reenvío y relaciones de confianza antes de que algo lo detenga? Conocer esa respuesta antes que un intruso real es lo que convierte una revisión de configuración en un control defendible.