Tailscale: auditoría expone fallas de root en SSH

Qué encontró la auditoría Tailworm sobre Tailscale y Headscale

El informe Tailworm, firmado por Erica Windisch de Cyberdione Labs Corporation, audita Tailscale v1.104.2 y headscale v0.29.5 en una ventana de pruebas del 22 al 24 de octubre de 2026. Su conclusión es incómoda: un usuario con acceso aprobado a un solo dispositivo puede alcanzar ejecución como root en otros servidores de la misma malla.

Los hallazgos se agrupan en cinco clases y tocan el servidor SSH embebido en tailscaled, el conector de aplicaciones experimental conn25, el servidor de control headscale, el cliente DERP y la función tailscale serve.

El punto de partida del reporte cuestiona el discurso comercial del sector: según los investigadores, las decisiones de diseño de Tailscale y headscale crearon un entorno propicio para el riesgo mientras se comercializa la seguridad como su diseño y propósito. El documento aclara que los investigadores no están asociados a Tailscale Inc., no trabajan para la compañía y no recibieron pago por el trabajo. Toda la investigación se hizo sobre software open source bajo licencia BSD-3, en equipos propios.

Para dimensionar el contexto: Headscale es, según XDA Developers, una implementación open source y autoalojada del servidor de control de Tailscale que conserva el cliente estándar en todos los dispositivos. Es decir, el mismo componente que este informe señala como vulnerable es el que muchos equipos eligen justamente para tener más control sobre su infraestructura.

Por qué Tailscale SSH es la pieza más peligrosa

Tailscale SSH no hace autenticación a nivel de usuario. La fase de autenticación del protocolo SSH se completa con el método none: la capa WireGuard ya identificó criptográficamente al dispositivo, y es esa identidad —no una contraseña ni un par de claves— la que evalúa la política. La consecuencia práctica es que un atacante no necesita material de credenciales más allá de un punto de apoyo en cualquier dispositivo permitido por la política.

Sobre ese modelo se apoyan tres hallazgos de severidad alta:

• Reenvío ssh -L a sockets unix que se ejecuta como root. Un par autenticado con una regla SSH que permita reenvío local puede hacer que el proceso tailscaled, que corre con privilegios de root, se conecte en su nombre a sockets restringidos. La reproducción verificada obtuvo uid=0(root) y el contenido de /etc/shadow, sin sudo ni pertenencia al grupo docker.
• Reenvío ssh -R que reemplaza sockets propiedad de root. El proceso privilegiado elimina un socket de root protegido y enlaza el listener del atacante en esa ruta, suplantando al servicio. Para daemons con canal de comandos, eso equivale a ejecución directa de código como root.
• Una condición de carrera (TOCTOU) que anula la lista blanca de rutas. La validación ocurre en el momento del chequeo, pero el enlace y el dial ocurren después. Un bucle de rename(2) a unas 170.000 conmutaciones de estado de ruta por segundo dentro de la sesión SSH gana la ventana entre chequeo y uso. El informe concluye que la lista blanca {home, /tmp, /run/user} no constituye una frontera de seguridad.

La cadena completa se demostró de punta a punta: el atacante mantiene el enlace secuestrado más de cuatro minutos, monta un man-in-the-middle consciente de la API local, captura una authkey byte a byte desde POST /localapi/v0/start y la usa en un nodo limpio. Resultado: un nodo no autorizado se une a la tailnet con la identidad de la víctima. En configuraciones con Tailnet Lock desactivado —el caso por defecto— el enrolamiento se ejecutó y se revirtió en el laboratorio.

conn25: el conector de apps que ignora las ACL

El segundo bloque apunta a conn25, el mecanismo de conector de aplicaciones que en v1.104.2 está presente pero es experimental. La idea del producto es razonable: designar dispositivos connector para que el tráfico hacia SaaS externo salga desde las direcciones de la organización y se gobierne en un solo lugar.

El problema es que el destino real lo declara el cliente en tiempo de ejecución a través de la API de registro, y nunca se valida contra los destinos configurados de la app. Solo se comprueba la familia de direcciones y la pertenencia al pool de tránsito. Además, las reglas de ingreso del conector aceptan el tráfico del pool antes de que corra la evaluación de control de acceso de la tailnet.

En la práctica, la concesión que dice que un dispositivo puede usar la app X a través del conector habilita elegir cualquier destino de egreso: subredes arbitrarias, la LAN y el loopback del propio conector, el servicio de metadatos de la nube (IMDS) y la internet abierta, con el tráfico saliendo enmascarado como el conector. En Kubernetes, donde el operador despliega los pods del conector con privilegios de contenedor completos, la posición alcanzada equivale al Service CIDR y al pod CIDR completos.

El informe es honesto sobre el alcance: un subnet-router o un exit-node etiquetado llegan al mismo estado final. La diferencia es el camino —un disparador a nivel de usuario en lugar de un rol de infraestructura—, sin paso de aprobación y sin huella de gobernanza. Los destinos de conn25 no aparecen en autoApprovers ni en las rutas, y expiran en la tabla DNAT del conector en aproximadamente una hora, renovable sin fricción.

Denegación de servicio sin cuenta y la API de administración al descubierto

Los hallazgos restantes son de disponibilidad y exposición:

• headscale (solo despliegues autoalojados): agotamiento de recursos sin autenticación. Basta con que el servidor de control sea alcanzable desde internet. El resultado es un bucle de caídas y el bloqueo del alta de dispositivos nuevos para toda la organización.
• Cliente DERP: lectura sin límite de la respuesta de un relay malicioso, con agotamiento de memoria del agente.
• tailscale serve: el reenvío TCP hacia un socket unix carece de una guarda que sí existe en la ruta HTTP, y hay una carrera en la autorización por montaje. Una configuración de una línea expone la API administrativa del nodo a pares remotos.

¿Se propaga como un gusano?

Sí, dentro de los límites de la política. Medido en laboratorio, la combinación de Tailscale SSH habilitado por política y los hallazgos de la clase 1 permite propagación automatizada a cada dispositivo que la política permita, sin contraseñas, sin claves robadas y sin interacción del usuario, en menos de un segundo por salto.

Dos límites estructurales aguantaron la prueba: las concesiones de acceso par a par acotan la propagación —el único control que la detuvo— y las credenciales de dispositivo ligadas a hardware (TPM o Secure Enclave) impiden el robo de identidad que hace persistente el compromiso. Todo lo demás cambió la velocidad de visibilidad, no la propagación.

Qué significa esto para tu startup

Si tu equipo usa Tailscale para llegar a servidores de producción, bases de datos o clústeres de Kubernetes, este informe te toca directamente. La buena noticia es que las mitigaciones son cambios de proceso, no compras: el propio informe señala que las correcciones se concentran en tres lugares —reglas de acceso par a par, credenciales ligadas a hardware y telemetría fuera del alcance del host comprometido—.

Acciones concretas, en orden de efecto:

• Reemplaza las reglas SSH amplias por concesiones par a par. Nunca reglas de aceptación por identidad completa o por tag. Es el control que en el laboratorio detuvo la propagación.
• Desactiva el reenvío SSH. En el SaaS, pon los campos de forwarding de cada regla en false. En headscale v0.29.5 el reenvío no se puede desactivar: se concede de forma incondicional en cada sesión aceptada, así que hasta que se corrija, trata cada concesión SSH de headscale como equivalente a root.
• No confíes en restringir SSH a cuentas sin privilegios. El informe es explícito: es defensa en profundidad y no mitiga estos hallazgos, que operan desde cuentas totalmente sin privilegios.
• Activa la expiración de claves de nodo en las flotas de servidores y usa estado de agente ligado a TPM o Secure Enclave.
• Construye la respuesta a incidentes sobre el borrado del dispositivo en el plano de control. Las claves de un nodo viven en un archivo que un atacante con root puede copiar; reinstalar el host no revoca una copia ya robada. Solo el borrado en el plano de control —o la expiración de clave— lo hace.
• Si autoalojas el plano de control, aplica límites de memoria, supervisión de reinicio y limitación de la tasa de registros.

Conclusión

Tailworm no afirma que Tailscale sea inseguro por diseño malicioso, sino que su modelo de confianza —identidad de dispositivo, no de usuario— convierte un punto de apoyo ordinario en acceso privilegiado a toda la flota a velocidad de máquina. Para un founder, la lectura útil es de arquitectura: cada capa que eliminas en nombre de la simplicidad es una capa que ya no te avisa cuando algo falla. Las correcciones del proveedor, según los investigadores, son pequeñas y tienen precedente en OpenSSH y Dropbear; las mitigaciones de arriba protegen antes y después de que lleguen.

Fuentes

• Tailworm — Security Assessment Report (fuente original)
• I replaced Tailscale's control server with Headscale, and my devices didn't notice — XDA Developers