Tailscale 1.104.4 corrige los fallos de privilegios SSH revelados por Tailworm

Tailscale ha corregido una serie de fallos en Tailscale SSH y en su función Serve con la versión 1.104.4. Las correcciones llegan tras el informe «Tailworm». Este mostró que un solo dispositivo comprometido podía obtener acceso root en otras máquinas a las que tenía permiso para llegar. Tailscale publicó cuatro boletines de seguridad, de TS-2026-014 a TS-2026-017, y explicó los detalles en una entrada de blog fechada el 28 de octubre de 2026. Quien use Tailscale SSH con reenvío de puertos debería actualizar.

Tailscale es un servicio VPN que une los dispositivos de una empresa en una sola red privada, llamada tailnet. Tailscale SSH le permite gestionar los inicios de sesión en esas máquinas en lugar de las claves SSH habituales.

Qué corrigen los cuatro boletines

Boletín	Qué falló	A quién afecta
TS-2026-014	El reenvío de sockets Unix por SSH se ejecutaba como root, así que podía alcanzar sockets reservados a root	Tailscale SSH cuando la política permite el reenvío local o remoto
TS-2026-015	La memoria crecía sin límite en las sesiones SSH, lo que podía provocar la caída de tailscaled	Nodos de Tailscale SSH, desde una sesión iniciada y permitida
TS-2026-016	Los backends de Serve en sockets Unix podían alcanzar sockets privilegiados, incluida la API local de tailscaled	Configuraciones que apuntan Serve a un socket Unix
TS-2026-017	Una condición de carrera en Serve con HTTP/2 filtraba cabeceras de App Capabilities entre puntos de montaje	Serve con TLS y dos o más puntos de montaje con requisitos distintos

Los cuatro están corregidos en la versión 1.104.4 o posterior, según el índice de boletines de Tailscale. Tailscale no asignó una calificación de gravedad a ninguno de ellos.

Un socket Unix es un canal local que los programas de una misma máquina usan para comunicarse entre sí. Algunos, como el socket de Docker, dan a quien los alcance el control total de la máquina.

Cómo funciona el ataque

La investigadora detrás del informe es Erica Windisch, de Cyberdione Labs, según The Hacker News. Probó Tailscale 1.104.2 y headscale 0.29.5, el servidor de control de código abierto, y enumeró 11 hallazgos.

En su laboratorio, tres métodos convirtieron una sesión SSH normal en acceso root. Uno enviaba una conexión reenviada a través de un proceso root hacia un socket reservado a root. Otro colocaba en su lugar un socket propiedad de root. Un tercero aprovechaba una condición de carrera con una comprobación de seguridad de rutas de archivo. Esa última cadena capturó una clave de inscripción y unió la máquina de un atacante a la red como servidor de confianza. Solo funcionó en redes sin Tailnet Lock, una función que obliga a los dispositivos de confianza a aprobar los nuevos.

Tailscale subraya los límites. Explotar los fallos requiere «un punto de apoyo existente en un par autorizado del tailnet», con SSH permitido por la política. La empresa afirma que los fallos no permiten que alguien de fuera inicie sesión en cualquier servidor de Tailscale SSH. Califica el riesgo de movimiento lateral limitado por la política, no de gusano que se propaga solo.

Una divulgación polémica

Todo fue rápido. Según Tailscale, la preocupación empezó a circular en redes sociales el viernes 23 de octubre, y la empresa empezó a investigar. Recibió el informe la mañana del sábado 24 de octubre, y la investigadora lo publicó unas dos horas después.

Windisch dijo a The Hacker News que el informe fue «reportado pero no coordinado». Afirmó que envió primero el informe y una prueba de concepto a Tailscale. Algunos investigadores criticaron la publicación sin una corrección coordinada, según The Hacker News y Brandefense.

Tailscale también revisó un informe aparte sobre Serve y Funnel con cinco hallazgos. Corrigió tres como errores y consideró que dos funcionaban según lo previsto. Un conector de aplicaciones aún no publicado, Conn25, tiene un fallo. «Los conectores de aplicaciones estables disponibles hoy no están afectados», dice Tailscale.

Qué significa para los desarrolladores

Los equipos que usan Tailscale SSH deberían aplicar esta actualización cuanto antes. El uso normal de la red sin estas funciones no figura como afectado.

• Actualiza los clientes a la versión 1.104.4 o posterior. Las correcciones están en el cliente, así que cada nodo que acepte Tailscale SSH necesita la nueva versión.
• Desactiva el reenvío si aún no puedes aplicar el parche. Define TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled y reinícialo. Tailscale SSH sigue funcionando sin reenvío.
• Endurece las reglas SSH. Sustituye las reglas amplias por permisos individuales de origen a destino, y nunca permitas cuentas de destino con privilegios, como aconsejan The Hacker News y Brandefense.
• Audita la configuración de Serve. Elimina cualquier reenvío de tailscale serve que apunte a un socket Unix que no necesites, sobre todo si es privilegiado.
• Si usas tu propio servidor, revisa headscale. Ambos medios informan de que headscale 0.29.5 no permite desactivar el reenvío, así que cualquier permiso SSH allí equivale en la práctica a root. La versión 1.104.4 del cliente no cambia el servidor.
• Activa Tailnet Lock. Según The Hacker News, bloqueó en el laboratorio el último paso de la cadena de la clave de inscripción.

Los consejos de la propia Tailscale son prudentes. «Según nuestra evaluación actual, no recomendamos que todo el mundo desactive Tailscale SSH», decía su actualización del 26 de octubre. Aplicar el parche y después limitar quién puede reenviar qué es, en cualquier caso, el camino más seguro.