Si usas Tailscale SSH, actualiza YA: el bug que te da acceso root con solo escribir \"-i\"

Un guión. El carácter más simple del teclado. Un solo - y ya eras root en cualquier servidor con Tailscale SSH.

No, no es un chiste. No es un PoC hipotético. Es real, está verificado por Tailscale, y fue reportado por Anthropic y Ada Logics. La vulnerabilidad TS-2026-009 permite a cualquier usuario con acceso SSH a un nodo Linux convertirse en root sin importar las ACLs que hayas configurado.

Y la forma de hacerlo es tan ridículamente simple que duele.

El bug: cómo un guión derribó un sistema de permisos

Tailscale SSH, la función de SSH integrada que Tailscale promociona como reemplazo moderno de OpenSSH, acepta nombres de usuario que empiezan con - (guión). En Linux, cuando Tailscale necesita verificar si un usuario existe, llama a getent(1) pasándole el nombre de usuario como argumento.

¿El problema? getent interpreta los argumentos que empiezan con guión como flags. La flag -i (o --no-idn) hace que getent imprima TODO el archivo passwd empezando por root.

Así que si un atacante se conectaba con el usuario -i, Tailscale SSH recibía el dump de getent con root como primer resultado y abría una sesión interactiva como root. ACLs violadas, permisos ignorados, root regalado.

Un error que viene de los 90

Thomas Ptacek, una leyenda viviente de la seguridad informática (el mismo de las reglas de seguridad de Tufao y el cracking de criptografía), lo resumió en HN:

"Este es un tipo de bug tan venerable y antiguo que se remonta al menos a AIX 3. Me alegra ver que todavía los hacen como antes."

AIX 3 se lanzó en 1990. Hace 36 años. Y aquí estamos, en 2026, con exactamente el mismo patrón de error en una de las herramientas de infraestructura más modernas del mercado.

La solución que divide opiniones

Tailscale lanzó el fix en la versión 1.98.9. ¿La solución? "Tailscale SSH ahora rechaza nombres de usuario con guiones al inicio."

Así nomás. Bloquear el carácter en vez de sanitizar correctamente los argumentos. Como señala el usuario cyberax en HN:

"¿Esa es la solución? Lo correcto sería usar '--' para separar argumentos."

Y tiene razón. En Unix, -- es el estándar POSIX para decir "de aquí en adelante, no interpretes nada como flag". Es una solución elegante, probada, y universal. En vez de eso, Tailscale optó por un parche más restrictivo.

¿A quién afecta realmente?

Si usas Tailscale SSH con la configuración por defecto, el bug no te afecta a menos que tengas ACLs que restrinjan el acceso a root mediante autogroup:nonroot. Pero exactamente ahí está el problema: esa es la configuración recomendada para entornos multi-tenant y servidores compartidos.

Usuarios de OpenSSH que solo usan Tailscale para la conexión de red (no SSH) no están afectados. El bug está específicamente en Tailscale SSH, no en la red subyacente de WireGuard.

Startup rewrite vs battle-tested OpenSSH

El hilo de HN tiene una corriente de fondo que vale la pena mencionar. Como dice luciana1u:

"tailscale ssh: reemplazar una base de código de 25 años probada en batalla con la reescritura en Go de una startup, y luego actuar sorprendidos cuando tiene bugs."

Y es una crítica válida. OpenSSH tiene 25 años de auditorías, exploits conocidos, fixes documentados, y una comunidad de seguridad que literalmente vive y respira SSH. Tailscale SSH tiene 4 años. No es que Tailscale sea incompetente — su equipo de seguridad respondió rápido y el bug no es trivial — pero la comparación es inevitable.

Qué hacer ahora (en serio)

El paso es simple pero urgente:

• Actualiza a Tailscale v1.98.9 o superior en todos tus nodos Linux
• Si usas autogroup:nonroot en tus ACLs, prioriza esta actualización
• Considera si realmente necesitas Tailscale SSH o te alcanza con OpenSSH sobre tu red Tailscale
• Monitorea tus logs de SSH por intentos de conexión con usuarios como -i, --help o -V

Para actualizar en Linux:

sudo apt update && sudo apt upgrade tailscale (Debian/Ubuntu)
sudo yum update tailscale (RHEL/Fedora)

Y verifica la versión: tailscale version debe mostrar >= 1.98.9.

Lo que este bug nos enseña

TS-2026-009 no es un bug exótico de criptografía cuántica ni un desbordamiento de buffer complejo. Es un error de parsing de argumentos. El tipo de error que los manuales de C mencionan en el capítulo 2. El tipo de error que cualquier pasante de seguridad sabe detectar. Y aún así, apareció en 2026 en una de las startups más sólidas del ecosistema.

La lección: la seguridad no es un destino, es un proceso. Y a veces, un solo guión es suficiente para recordártelo.

Comparte esto con alguien que todavía confía ciegamente en que su VPN moderna no tiene bugs de los 90.