Tailscale SSH y la escalada de privilegios: el riesgo ya estaba adentro

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

Mi receta de SSH lleva años congelada: puerto distinto del 22, fail2ban con reglas duras, firewall que abre solo lo que se usa. Cuando las mallas VPN con WireGuard se pusieron de moda, la recomendación sonora era adoptarlas completas: cero puertos expuestos, todo el tráfico dentro del túnel. Tailscale promete exactamente eso, y encima agrega una capa cómoda de nombre poco imaginativo: Tailscale SSH, que intercepta tus conexiones dentro de la malla y aplica las políticas de acceso de la propia herramienta. Esta semana esa capa cómoda está en el horno: la empresa confirmó que está investigando problemas de escalada de privilegios en Tailscale SSH y publicó su primer informe el 26 de octubre de 2026.

Qué confirmó la empresa

Según el informe, la mayoría de los hallazgos es de un tipo específico: alguien ya autorizado para conectarse por Tailscale SSH puede ejecutar acciones más allá de los permisos del usuario local que le corresponde, incluso llegar a privilegios elevados. Fíjate bien en el detalle: el problema no es un desconocido golpeando desde internet, sino que la jerarquía interna de permisos se rompe por dentro. La empresa dice que los problemas son serios, que el exploit depende de los permisos y la configuración de cada máquina, que aún verifica el alcance total con ayuda de especialistas externos, y que por ahora no recomienda que todos deshabiliten Tailscale SSH. Los fixes están implementados y en pruebas, con una versión parcheada del cliente prometida para fin del martes 27 de octubre; el advisory con los CVE y el post técnico llegarían después.

Qué conviene ajustar hoy

Con advisory aún pendiente, el informe entrega mitigaciones concretas y baratas. Revisar las políticas de acceso SSH: quién conecta y a qué realmente necesita entrar. Deshabilitar el SSH forwarding si no se usa: basta TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled y reiniciar; ese cambio mitiga varios de los hallazgos más serios de un tirón. Habilitar el modo check, que agrega un paso de login antes de cada sesión —ojo, mitiga, no corrige la escalada—. Y dejar listo el update del cliente para cuando salga.

La lección: la malla cambia el perímetro, no lo borra

Acá va mi opinión: el error de fondo es psicológico, no técnico. Cuando el puerto no está expuesto, uno relaja la guardia, como si «poder entrar» y «poder hacer todo» fueran lo mismo. Nunca lo son. Tailscale SSH funciona porque tailscaled, que corre con privilegios de root, hace de terminal server de tus sesiones: cada capa de conveniencia que intercepta el transporte es una capa con privilegios que hay que auditar, igual que auditarías un sshd. No por nada la mitigación más recomendada es cortar el forwarding: es exactamente lo que hace de puente entre redes.

Mi flota usa SSH clásico, no la función Tailscale SSH, así que el bug no me toca directamente. Pero el patrón aplica en todas partes: un software con root que decide quién eres una vez conectado. Le agregué una regla a mi checklist: en cualquier sistema de acceso, lo que importa no es solamente quién llega, sino qué puede hacer cuando ya está adentro, y qué capa decide eso. Si esa capa es la misma herramienta que te da la comodidad, audítala el doble.

Y un aplauso para la transparencia: informe público, mitigaciones mientras investigan, advisory comprometido. Ojalá todos los proveedores respondieran así con lo incómodo.

Fuente: Tailscale SSH: Investigation and remediation update, del blog de Tailscale.

Fuente de inspiración: Tailscale SSH: Investigation and remediation update