El 14 de julio Tailscale publicó el boletín TS-2026-009 y la historia detrás es de esas que te hacen mirar dos veces la configuración de tu tailnet. No es un exploit sofisticado ni una cadena de zero-days. Es algo más viejo y más incómodo: un argumento mal validado en Tailscale SSH que le permitía a un usuario sin privilegios abrir una sesión como root, saltándose por completo las ACL que tú mismo escribiste para impedirlo.
Qué pasó, en simple
Si conectabas por Tailscale SSH a un nodo Linux con el usuario -i, el daemon pasaba ese string como argumento a getent(1). En GNU getent, los argumentos que empiezan con guion se interpretan como flags. Resultado: --no-idn, y getent escupía el archivo /etc/passwd completo partiendo por la línea de root. Tailscale tomaba eso como una entrada válida y te abría una shell interactiva como root. Ni flag, ni pregunta, ni auditoría.
Lo más feo es que esto burlaba la regla que la mayoría configura con buenas intenciones: autogroup:nonroot en las ACL, justamente para que nadie aterrice como root por accidente. Tus reglas, las que pasaste una tarde tuneando, quedaron neutras con un solo guion.
No era el único agujero del release
El boletín TS-2026-009 incluye otros tres bugs que hablan de un patrón:
Bypass por UID numérico. Podías conectarte como 0@host y Tailscale lo aceptaba como root, porque la ACL solo revisaba el nombre de usuario, no el ID numérico. Validación de identidad a medias.
Path traversal que congela un core. Un request mal formado a Tailscale Serve o Tailscale Funnel caminaba el path segmento por segmento esperando llegar a /. Si el path no empezaba con /, el loop no terminaba nunca y un core quedaba al 100%. En Funnel, lo disparaba cualquiera desde internet, sin autenticarse.
Loopback accesible vía Services. Si publicabas un Service, un usuario con ACL podía llegar a procesos bindeados a 127.0.0.1 en el nodo, en puertos que nunca publicaste. Filtro de paquetes insuficiente.
Lo que me molesta de este tipo de bug
No es que sean complejos. Al contrario: el del guion es casi un ejercicio de clase. Lo que me molesta es que aparecen en herramientas que, justamente, venden la promesa de ser la forma más simple y segura de exponer servicios. Tailscale es excelente, lo uso, lo recomiendo. Pero este episodio es un recordatorio: simplicidad no significa superficie chica, significa superficie distinta, y hay que entenderla.
Si operas un tailnet con Tailscale SSH, lo que tienes que hacer hoy, no mañana, es subir a 1.98.9 o superior. Si tienes nodos con Serve o Funnel expuestos, lo mismo. Y si todavía no tienes autogroup:nonroot bien configurado, este bug es el incentivo que te faltaba.
Lo que te llevas
Dos cosas, en mi pega las pongo en la pizarra:
Uno: cualquier input que pasa como argumento a un binario externo (exec, subprocess, getent) tiene que ser validado contra -, --, saltos de línea y todo lo que la shell o el binario pueda reinterpretar. El bug de Tailscale es hijo directo de un argv mal saneado, patrimonio de los 90. Sigue pasando.
Dos: no te confíes de que tu modelo de seguridad es seguro solo porque la herramienta es buena. Tailscale es buena y tuvo cuatro bugs serios en un solo release. La superficie vive en los bordes: en cómo interpretas un username, en cómo filtras un puerto, en cómo terminas un loop. Los centros casi siempre están bien, las puntas casi siempre no.
Si administras infra con Tailscale, actualiza, revisa las ACL y aprovecha para auditar a qué le has abierto Serve y Funnel. El resto del trabajo, ya lo hizo el equipo de Tailscale publicándolo el mismo día del fix.
Fuente de inspiración: Security Bulletins · Tailscale (TS-2026-009)
