Tailworm: fallos en Tailscale SSH dan root desde un nodo atacado

El fin de semana del 24 y 25 de octubre de 2026, Cyberdione Labs publicó los detalles de 11 vulnerabilidades en Tailscale, la VPN mesh basada en WireGuard, y en headscale, el servidor de control de código abierto que las empresas pueden alojar por su cuenta. Los investigadores las llaman en conjunto Tailworm. Las encontraron durante una auditoría de Tailscale 1.104.2 y headscale 0.29.5 y las reprodujeron en laboratorio sobre software publicado y sin modificar (BleepingComputer).

La publicación se hizo antes de que existieran parches. Según SecurityWeek, la decisión recibió críticas en las redes sociales, mientras que la fundadora de Cyberdione Labs, Erica Windisch, sostiene que dar a conocer los fallos rápidamente acelera la corrección y que se encontraron «con poco esfuerzo». En la fecha de los artículos no constan CVE asignados, y ni Tailscale ni el informe mencionan explotación activa (SecurityWeek).

El problema principal: Tailscale SSH

Tailscale SSH es el servidor SSH integrado en tailscaled: se ejecuta como root y concede el acceso según la identidad del dispositivo y las políticas de la tailnet, sin contraseñas ni claves. Según el informe citado por los dos medios, el reenvío de sockets Unix (ssh -R y ssh -L) realiza las comprobaciones de rutas y las operaciones con archivos con privilegios de root. Las condiciones de carrera y la falta de reducción de privilegios permiten a una sesión normal sustituir, abrir o borrar recursos privilegiados.

De los seis hallazgos de gravedad alta, cuatro afectan a Tailscale SSH (SecurityWeek). Resultados demostrados en laboratorio:

• ejecución de código como root en los servidores de destino;
• robo de las claves de registro, con las que se pueden añadir dispositivos no autorizados a la tailnet;
• borrado de archivos arbitrarios con privilegios de root.

El requisito es un dispositivo aprobado más una regla SSH que permita el reenvío. En headscale el reenvío se concede automáticamente; en el servicio SaaS de Tailscale depende de cada regla (BleepingComputer).

Una cadena que se propaga sola

Según SecurityWeek, los investigadores demostraron que los fallos son wormable: no hacen falta credenciales del usuario, y un ataque automatizado que encadena los bugs pasó de una máquina a otra por todos los servidores accesibles por Tailscale SSH según la política, en menos de un segundo por salto y sin interacción. El punto de entrada puede ser cualquier compromiso de un nodo: phishing, una aplicación web vulnerable, un paquete de software malicioso. El titular de The Hacker News describe el mismo escenario: un dispositivo comprometido que llega a root en otros servidores.

Técnicas MITRE ATT&CK pertinentes (nuestra clasificación): T1021.004 (SSH como servicio remoto), T1068 (explotación para la escalada de privilegios) y T1210 (explotación de servicios remotos) para la propagación.

Los demás fallos

El informe describe además (BleepingComputer, SecurityWeek):

• app connector (conn25, función experimental): el tráfico se traduce hacia destinos elegidos por el atacante sin validación, y las ACL no se aplican al destino real. Con un dispositivo que tenga la capability del conector se alcanzan los servicios de metadatos de la nube (robo de credenciales, T1552.005), las LAN internas y, en Kubernetes, todos los servicios del clúster;
• headscale: agotamiento de recursos sin autenticación (crecimiento de la memoria, vaciado de la caché), al alcance de cualquiera que llegue al servidor. Resultado: caídas repetidas del servidor de control y bloqueo del registro de nuevos dispositivos en toda la organización;
• cliente DERP (el relay presente en cada agente): lectura sin límites de la respuesta de un relay malicioso, que agota la memoria del cliente;
• tailscale serve: el reenvío TCP hacia un socket Unix carece de una protección que sí existe en la ruta HTTP, y una condición de carrera en la autorización de cada mount deja pasar una parte de las peticiones. Resultado: acceso remoto a la API de administración del nodo.

La respuesta de Tailscale

Mike Shaver, VP of Engineering de Tailscale, escribió en Reddit que la empresa ya estaba realizando una investigación propia, con especialistas externos, cuando llegó el informe. Según Tailscale, la mayoría de los problemas afectan a lo que ocurre después de que alguien está autorizado a conectarse: una sesión puede hacer más de lo permitido al usuario local configurado. Es grave, pero no equivale a un atacante no autenticado que se conecta a máquinas arbitrarias; el impacto depende de cómo esté configurado el acceso SSH (SecurityWeek, BleepingComputer).

Tailscale no recomienda desactivar Tailscale SSH y se proponía publicar el cliente corregido antes del martes 27 de octubre. Según la actualización de SecurityWeek, la empresa publicó después los detalles completos, las correcciones distribuidas y cuatro boletines de seguridad con las indicaciones de remediación. Las fuentes no indican el número de la versión corregida: compruébalo en los boletines de Tailscale. Para headscale, las fuentes no mencionan una versión corregida.

Impacto para las empresas europeas e italianas

Tailscale se usa para el acceso remoto de administradores, desarrolladores y proveedores: un solo portátil comprometido con acceso SSH a muchos servidores se convierte en el punto de partida para llegar a root en todos. Las claves de registro robadas permiten seguir en la red incluso después de limpiar el primer dispositivo. Para las entidades NIS2, el caso afecta a la gestión de vulnerabilidades y al control de los accesos privilegiados, incluidos los de proveedores y mantenedores. En sanidad conviene revisar primero los nodos que dan acceso a sistemas clínicos.

Qué hacer ya

1. Actualiza los clientes de Tailscale a la versión indicada en los boletines de Tailscale, empezando por los servidores que aceptan Tailscale SSH.
2. Desactiva el reenvío SSH donde no haga falta: TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled y reinicia el servicio. Tailscale SSH sigue activo y, según Tailscale, se mitigan varios de los fallos más graves.
3. Restringe las políticas SSH a los usuarios y dispositivos que realmente las necesitan, al menos hasta que se cierre el análisis.
4. headscale: no expongas el servidor de control más de lo necesario y sigue las actualizaciones del proyecto; recuerda que allí el reenvío se concede automáticamente.
5. App connector y serve: comprueba quién tiene la capability de los conectores y qué reenvíos hacia sockets Unix están configurados.
6. Detección: busca en la tailnet dispositivos registrados recientemente y no reconocidos, sesiones SSH con reenvío de sockets Unix y archivos del sistema borrados o sustituidos. Si tienes dudas, rota las claves de registro.

Cómo ayuda ARXDOME

ARX Sentry recoge de los servidores Linux eventos de seguridad, inventario del software y control de integridad de los archivos en las carpetas elegidas: te ayuda a encontrar las máquinas con Tailscale, ver su versión y detectar accesos privilegiados o archivos del sistema modificados. Si un nodo es sospechoso, ARX Shield lo aísla de la red hasta que se verifique.

Última actualización: 27 de octubre de 2026