Tailscale ha publicado la versión 1.104.4 para corregir los fallos de su servidor SSH conocidos como Tailworm, que permitían a un dispositivo comprometido obtener root en otros servidores de la red. Afecta a quien use Tailscale SSH en Linux o en la compilación de código abierto de macOS. Actualiza hoy esos nodos o desactiva el reenvío mientras tanto.
Lo esencial
- Cyberdione Labs publicó 11 hallazgos, bautizados Tailworm, que afectan al cliente de Tailscale 1.104.2 y a headscale 0.29.5, el servidor de control autoalojado (SecurityWeek).
- Tailscale recibió el informe la mañana del sábado 24 de octubre, unas 2 horas antes de que se hiciera público.
- La versión 1.104.4 cubre 4 boletines de seguridad, entre ellos TS-2026-014 (reenvío de sockets SSH). No llevan identificadores CVE ni puntuación de gravedad (BleepingComputer).
- En las pruebas del investigador, el reenvío al socket de control de Docker dio una shell root y permitió leer /etc/shadow sin derechos de administrador (The Hacker News).
- Según The Hacker News, las incidencias relacionadas en headscale siguen sin parche.
¿Me afecta si uso Tailscale en la empresa?
Los fallos de reenvío que corrige la 1.104.4 están en el servidor de Tailscale SSH, la función que deja a Tailscale gestionar el acceso SSH a tus máquinas. Ese servidor solo se ejecuta en Linux y en la compilación de código abierto de macOS. Si tienes Tailscale SSH activado en servidores, estás en el grupo afectado.
Es un escenario habitual en startups y pymes técnicas: Tailscale como VPN de equipo y, a la vez, como puerta de entrada a los servidores. Aunque no uses Tailscale SSH, actualiza igualmente los clientes: el informe recoge 11 hallazgos, no uno.
¿Qué puede hacer de verdad un atacante?
Primero necesita haber comprometido un dispositivo de tu red Tailscale: un portátil, un servidor. Desde ahí podría explotar el fallo contra cualquier servidor al que ese dispositivo llegue por Tailscale SSH, siempre que la regla de acceso permita el reenvío. El servidor hacía ese reenvío como root, así que apuntar al socket de Docker bastaba para tener una shell root.
La 1.104.4 cambia eso: el reenvío se hace con el usuario conectado y se apoya en los permisos del sistema operativo.
Sobre la etiqueta: los investigadores lo calificaron de «wormable». Tailscale rechaza que sea un gusano y habla de movimiento lateral limitado a las conexiones que tu política ya permite (SecurityWeek). Ni la empresa ni el informe mencionan explotación en el mundo real.
¿Basta con actualizar?
Si el servidor está limpio, sí. Si pudo estar comprometido, no. Una clave de dispositivo robada sigue siendo válida hasta que eliminas el dispositivo en el plano de control. Reinstalar la máquina no invalida esa clave.
Y si usas headscale, el cliente corregido no resuelve todo lo que te afecta.
Qué hacer hoy
- Haz inventario de los nodos Linux (y macOS de código abierto) que tienen Tailscale SSH activado.
- Actualízalos a la 1.104.4 o posterior. Aprovecha para actualizar el resto de clientes.
- Si un servidor no se puede actualizar todavía, define
TS_SSH_DISABLE_FORWARDING=1en el entorno del servicio tailscaled y reinícialo. Desactiva el reenvío sin apagar Tailscale SSH. - Revisa las reglas SSH de tu política para que solo accedan los usuarios y dispositivos que lo necesitan. Escríbelas como pares dispositivo a dispositivo: en las pruebas, eso frenó la propagación.
- Si sospechas de algún portátil o servidor, elimínalo en el panel de control para invalidar su clave. Después, reinstálalo.
- Si tienes headscale autoalojado, sigue su canal de avisos y aplica el parche cuando salga.
Qué significa para una pyme
Lo preocupante no es tanto el fallo como el sitio donde está. En muchas empresas pequeñas, Tailscale es la única capa entre un portátil y producción. Cuando esa capa reenvía como root, cualquier equipo comprometido se convierte en llave maestra para todos los servidores a los que llega.
El riesgo inmediato es moderado: hace falta un atacante con un pie dentro y nadie ha reportado explotación. Pero los detalles son públicos desde el fin de semana del 24 de octubre y el parche llegó después, así que el margen corre en tu contra. Actualizar cuesta minutos.
La lección de fondo va más allá de este parche. Muchas pymes dejan la política de Tailscale en «todos a todo» porque es cómodo. Este caso muestra el precio. Lo que limitó el daño en las pruebas fueron reglas estrechas, de dispositivo a dispositivo, y claves vinculadas a hardware como un TPM, que impidieron reutilizar una identidad robada. Si nunca has revisado tu política de acceso con ese criterio, hazlo esta semana. Si quieres apoyo para esa revisión, tienes nuestro servicio de ciberseguridad.
Y no desactives Tailscale SSH por reflejo. Tailscale no lo recomienda, y la variable de entorno te da una salida intermedia mientras actualizas.
Preguntas frecuentes
¿Tiene CVE o puntuación CVSS?
No. Los 4 boletines que cubre la 1.104.4, entre ellos TS-2026-014, no llevan identificadores CVE ni puntuación de gravedad.
¿Se está explotando?
Ni Tailscale ni el informe de Cyberdione Labs mencionan explotación en el mundo real.
¿Debo desactivar Tailscale SSH?
No. Tailscale no lo recomienda. Si no puedes actualizar todavía, desactiva solo el reenvío con TS_SSH_DISABLE_FORWARDING=1.
Fuentes
- BleepingComputer – Tailscale warns of SSH flaws allowing root privilege escalation
- SecurityWeek – Tailscale Rushes Patches After Uncoordinated Disclosure of 'Tailworm' Flaws
- The Hacker News – Tailscale Patches SSH Flaws That Could Let Hacked Devices Gain Root Access on Other Servers
- The Hacker News – Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers
