Publicados los detalles, pero aún no hay forma de cerrar las brechas detectadas.

El acceso habitual a un servidor a través de una red protegida puede convertirse en un control total del sistema sin necesidad de la contraseña del administrador. La investigadora Erika Vindish de Cyberdione Labs describió en el informe Tailworm 11 problemas de seguridad en Tailscale y headscale, incluidos métodos para obtener privilegios root mediante el SSH integrado de Tailscale. Aún no hay correcciones para los nuevos hallazgos.
Las pruebas se realizaron del 22 al 24 de octubre de 2026 en Tailscale 1.104.2 y headscale 0.29.5. El problema principal está relacionado con la redirección de sockets Unix, por los que las aplicaciones en el equipo se comunican entre sí. El servicio tailscaled se ejecuta con privilegios de root y, en determinadas conexiones SSH con reenvío, accede a sockets protegidos en nombre del superusuario, aunque al participante remoto no se le habían concedido esos permisos.
En el laboratorio, una sesión SSH permitió acceder al socket de Docker y ejecutar comandos como root, incluida la lectura de un archivo protegido. Otra técnica aprovechó una condición de carrera entre la comprobación de la ruta al socket y la operación posterior. Vindish también mostró la sustitución de sockets protegidos y la intercepción de las claves de registro de dispositivos. Establecerse en la red con las claves robadas fue posible solo con Tailnet Lock desactivado.
Para el ataque es necesario controlar un dispositivo al que las reglas de la red permiten conectarse al servidor objetivo mediante Tailscale SSH con reenvío. La mera presencia de Tailscale en el equipo no es suficiente. En el laboratorio, el ataque automatizado se desplazaba a otros nodos permitidos en menos de un segundo por salto. No hay información sobre una propagación similar en redes reales.
Otros hallazgos afectan a conectores experimentales de aplicaciones, Tailscale Serve, los retransmisores DERP y el servidor headscale. La función conn25 permitía dirigir tráfico a direcciones fuera de las reglas aprobadas, incluidos servicios internos e interfaces en la nube para la emisión de credenciales. En headscale se identificaron formas de sobrecargar la memoria sin autorización, impidiendo la conexión de nuevos dispositivos.
Tailscale recibió el informe, y el vicepresidente de ingeniería Mike Shaver confirmó que la compañía ya había investigado problemas similares y está preparando correcciones. Los desarrolladores aún no han confirmado cada hallazgo y están aclarando las configuraciones afectadas. A los nuevos problemas no se les han asignado CVE y no hay puntuaciones CVSS 3.1 o 4.0. La autora del informe clasificó los errores más peligrosos como de alto riesgo.
Hasta que salgan las correcciones, Tailscale recomienda limitar el acceso SSH y desactivar el reenvío innecesario con la variable TS_SSH_DISABLE_FORWARDING=1 y reiniciar tailscaled. La compañía no recomienda desactivar completamente Tailscale SSH por ahora. En headscale 0.29.5, las reglas de acceso no permiten prohibir el reenvío por separado, por lo que las conexiones permitidas requieren un control adicional.
En julio ya se corrigió otro problema de permisos en el ecosistema: los desarrolladores de OpenWrt corrigieron la vulnerabilidad luci-app-tailscale-community, que permitía ejecutar comandos como root desde la interfaz de administración. Sin embargo, Tailworm afecta a otro código y a otro mecanismo de ataque. Por ahora las conclusiones se basan en las pruebas del autor del informe y no existe una verificación pública e independiente de los 11 hallazgos.