Tailscale explicó la madrugada de este miércoles 28 de octubre en su blog qué falló en Tailscale SSH, su servidor SSH integrado, y cómo lo ha arreglado. Las correcciones están disponibles en Tailscale v1.104.4: si usas Tailscale SSH, en casa o en el trabajo, actualiza a esa versión o a una posterior.
El problema no estaba en quién puede conectarse, sino en lo que podía hacer una sesión ya autorizada: en ciertas condiciones, una sesión SSH autenticada podía ir más allá de los permisos de su usuario local, también a través del reenvío SSH. Para aprovecharlo hay que tener ya acceso a un equipo autorizado de la tailnet, la red de Tailscale de cada usuario o empresa. La compañía lo detalla en cuatro boletines de seguridad fechados el lunes 26 de octubre.
| Boletín | Qué permitía | Qué lo corrige en la 1.104.4 |
|---|---|---|
| TS-2026-014 | Llegar con el reenvío SSH a sockets solo para root (Docker, API local de tailscaled) | El reenvío de sockets Unix se hace como el usuario autenticado, no como root |
| TS-2026-015 | Agotar la memoria del equipo y tumbar tailscaled | La memoria de cada sesión tiene límite y se libera al desconectar |
| TS-2026-016 | Tomar el control completo del nodo con Serve y sockets Unix | Restringe los reenvíos TCP al socket de tailscaled y revisa el destino en cada conexión |
| TS-2026-017 | Que Serve con TLS mezclara permisos entre montajes | Los permisos salen de cada petición, no de un estado compartido |
Qué fallaba en Tailscale SSH
Tailscale SSH usa las identidades y las políticas de acceso de Tailscale: el administrador decide quién se conecta a qué equipos y con qué usuario local de Linux o Unix. Como cualquier servidor SSH, necesita privilegios elevados para abrir sesiones con distintos usuarios, y esos privilegios no deben colarse en la sesión de quien se conecta. Eso es lo que falló: «En estos casos no aplicamos esos límites correctamente», reconoce la compañía.
En el TS-2026-014, el servidor SSH vive dentro de tailscaled, el proceso que se ejecuta con privilegios de root, y comprobaba las rutas de los sockets Unix solo por su nombre, pero operaba como root. Con el reenvío local (ssh -L) o remoto (ssh -R) permitido en las políticas, un usuario autenticado podía alcanzar sockets reservados a root, como el de Docker o la API local de tailscaled. El TS-2026-015 dejaba a una sesión autenticada hacer crecer sin límite la memoria de tailscaled hasta que el sistema lo cerrara, y su caída interrumpe todas las conexiones de Tailscale del equipo.
También en Serve y Funnel
El informe incluía cinco hallazgos en Tailscale Serve y Funnel: tres eran fallos y la 1.104.4 los corrige; los otros dos, explica, son comportamiento previsto. El fallo que señalaba en Conn25, la próxima generación de conectores de aplicaciones, no llegó a los usuarios: sigue en preproducción.
En el TS-2026-016, con Serve publicando sockets Unix, un reenvío TCP se hacía como root y daba acceso remoto a la API local, lo que permitía «tomar el control completo del nodo» en equipos donde un operador o usuario local puede escribir la configuración de Serve o sus rutas. El TS-2026-017 afecta a quien usa Serve con TLS y dos o más montajes con permisos distintos en el mismo equipo: quien tenía permiso para uno podía llegar a recibir respuestas privilegiadas de otro.
Hace falta estar dentro: no es un gusano
El informe se publicó con el nombre de «Tailworm», y eso hizo que se preguntara si era un gusano informático. El blog responde que no: lo descrito no es «malware que se replica a sí mismo y se propaga automáticamente entre máquinas», sino un movimiento lateral limitado a las conexiones que permite el archivo de políticas de la tailnet. Un atacante sin autenticar no puede conectarse a cualquier servidor de Tailscale SSH: necesita un punto de apoyo previo en un equipo autorizado, con el acceso SSH permitido expresamente, y solo podía llegar a las máquinas a las que esas políticas ya dejaban conectarse.
Cómo respondió la compañía
Las dudas empezaron a circular en redes sociales el viernes 23 de octubre, y la investigación arrancó ese día con ayuda de especialistas externos. El informe del investigador llegó la mañana del sábado 24 de octubre y se hizo público dos horas después. Los arreglos se prepararon y probaron durante el fin de semana y el lunes 26 de octubre, día en que se publicó una primera valoración con precauciones recomendadas. La compañía dice haber añadido, además, salvaguardas en la arquitectura contra problemas parecidos.
Qué tienes que hacer
Actualiza a la 1.104.4 o posterior en los equipos con Tailscale SSH o Serve. Además, la compañía aconseja revisar las políticas de SSH para que el acceso quede limitado a los usuarios y equipos que lo necesitan, y plantearse el modo de comprobación (SSH check mode) en los sistemas delicados, que pide una verificación de identidad adicional.
Si no puedes actualizar y tienes el reenvío permitido, el boletín TS-2026-014 da una mitigación: añadir TS_SSH_DISABLE_FORWARDING=1 al entorno del servicio tailscaled y reiniciarlo. Así se desactiva el reenvío sin apagar el resto de Tailscale SSH.
Te puede interesar
Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.
| Imagen | Producto | Características | Comprar |
|---|---|---|---|
 |
Norton 360 Deluxe 2026, 5 dispositivos | 1 año con renovación automática · antivirus y Secure VPN · Dark Web Monitoring · descarga digital | Ver precio en Amazon |
 |
ESET Home Security Essential 2026, 3 dispositivos | 1 año · inspector de red · banca online y navegación seguras | Ver precio en Amazon |
 |
McAfee Total Protection 2026, 5 dispositivos | 15 meses · antivirus, VPN y gestor de contraseñas · detector de fraudes | Ver precio en Amazon |
 |
Yubico Security Key C NFC | llave FIDO2/WebAuthn y U2F · USB-C y NFC · sin batería · no admite contraseñas de un solo uso | Ver precio en Amazon |
Escrito por Eloy Andrade
