El boletín TS-2026-014 de Tailscale, del 26 de octubre, cabe en una frase: el servidor SSH «validated Unix socket paths lexically but would perform the operations as root». Comprobaba un nombre y después abría el fichero con los permisos del demonio, que es root. Entre comprobar y abrir cabe una carrera. Al otro lado, dice el mismo boletín, hay «root-only sockets such as the Docker socket or the tailscaled local API». El parche llegó anoche: la etiqueta v1.104.4 se creó el 27 de octubre a las 23:01 UTC. Pero el fallo concreto no es lo que nos interesa. Lo que nos interesa es la pregunta que deja encima de la mesa: en tus servidores, ¿quién decide quién es root?
Los cuatro boletines, en una tabla
Tailscale publicó cuatro el mismo día. Los cuatro se corrigen en la misma versión. Vale la pena leerlos juntos porque dos de ellos no son de SSH, y mucha gente va a cerrar la pestaña al llegar a «es un fallo de Tailscale SSH, yo eso no lo uso».
Los cuatro dicen lo mismo en el pie: «fixed in Tailscale version 1.104.4 or newer». En el repositorio público no hay etiqueta 1.104.3: se salta directamente de la 1.104.2 a la 1.104.4, y entre ambas hay 42 confirmaciones. Volveremos a ellas, porque cuentan más que las notas.
La frase que explica los cuatro
El demonio tailscaled corre como root en una instalación normal sobre Linux —existe un modo de red en espacio de usuario, pero no es lo que tienes en el servidor—, y para lo que hace lo necesita: crea una interfaz de red, escribe rutas y toca el cortafuegos del sistema. Eso no es un defecto de diseño, es el precio de que una VPN «simplemente funcione» sin pedirte nada. Pero convierte al demonio en el sujeto de todas las operaciones que hace en tu nombre. Cuando ese proceso recibe de un par una petición del tipo «ábreme este socket» y decide si vale mirando el texto de la ruta, lo que queda en medio es la distancia entre comprobar y actuar.
Esa distancia tiene nombre desde hace décadas y se gana cambiando lo que hay detrás del nombre en el momento justo: un enlace simbólico que apunta a un sitio inocuo cuando se comprueba y a otro cuando se abre. El boletín TS-2026-016 lo describe sin rodeos en la otra función afectada: el guardia contra enlaces simbólicos «only ran during configuration reload rather than per dial». Se comprobaba una vez, al principio, y después se confiaba.
Por qué «el socket de Docker» es la parte seria
El boletín pone dos ejemplos de «socket de solo root» y no son equivalentes.
- El socket de Docker. Quien puede escribir en
/var/run/docker.sockpuede pedirle al demonio de Docker que arranque un contenedor con el sistema de ficheros del anfitrión montado dentro. Eso no es «acceso a Docker»: es root en la máquina, por diseño y documentado desde siempre. En un servidor de aplicaciones ese fichero existe. - La API local de tailscaled. Es la que usa el propio comando
tailscalepara hablar con el demonio. Quien llega a ella manda sobre la pertenencia del nodo a la red. Por esa vía, el boletín TS-2026-016 —el deserve, no el de SSH— lo llama por su nombre: «full node takeover».
El reenvío de sockets Unix por SSH es viejo y aburrido: existe desde OpenSSH 6.7, de octubre de 2014, y se usa a diario para llegar a una base de datos sin publicarla. La diferencia, aquí, es quién abría el otro extremo. En el SSH de siempre lo abre un proceso que ya lleva tu identidad. En este caso lo abría el demonio.
La pregunta de verdad: ¿quién decide quién es root en tu máquina?
El SSH de toda la vida reparte esa decisión entre cosas que viven en tu máquina: la configuración de sshd, las claves de authorized_keys, PAM, los grupos y sudoers. Son ficheros. Se leen, se versionan y se auditan sin pedirle permiso a nadie.
Tailscale SSH quita todo eso del camino. No hay claves que repartir ni authorized_keys que mantener: ese es el argumento de venta, y es bueno de verdad —quien haya heredado un parque con claves de un becario de 2019 sabe de qué hablamos—. A cambio, quién entra y como qué usuario lo decide una regla en la política del tailnet, que vive en el plano de control. Y como la conexión no la termina sshd sino tailscaled, el proceso que te abre la sesión es el mismo que lleva la VPN.
Es una decisión de arquitectura legítima. Lo que hace falta es saber que se ha tomado, porque cambia tres cosas a la vez: dónde se escribe la regla, quién puede cambiarla y qué ocurre cuando esa capa tiene un fallo. La tercera se contestó sola el fin de semana pasado. Las otras dos las sigues contestando tú.
Hay un detalle en la documentación que lo deja más claro que cualquier boletín, y casi nadie lo ha leído. El «modo de comprobación» de Tailscale SSH exige volver a autenticarse —con MFA, si la tienes configurada— antes de abrir sesión. Suena exactamente a lo que quieres. La letra pequeña es esta, literal: «Once re-authenticated to a destination, the user can access the device and any other device in the tailnet without re-verification for the next 12 hours». Y el periodo por defecto son doce horas. La comprobación, salvo que escribas un checkPeriod propio para esa conexión, es por persona y por red, no por máquina. Es la misma conversación que ya tuvimos cuando escribimos que un túnel entre sedes no tiene a quién pedirle un segundo factor: el segundo factor protege el momento de entrar, no lo que hay detrás.
De ahí sale la frase que nos llevamos nosotros: una malla no es segmentación. Lo que decide qué alcanza a qué dentro de una malla es una lista de reglas. Si esa lista dice «los portátiles del equipo llegan a los servidores», la malla está haciendo exactamente lo que le pediste, y el portátil comprometido también.
Lo que cuenta el parche
Las correcciones de seguridad se leen mejor en el código que en la nota. Entre la 1.104.2 y la 1.104.4 hay 42 confirmaciones y treinta de ellas tocan el mismo directorio, ssh/tailssh. No son parches puntuales: es un cambio de forma. Los títulos lo cuentan solos —«route SSH forwarding through the privileged monitor», «dial TCP forwards as the bound user», «relay Unix forward payloads as the bound user», «launch sessions via the monitor», «enforce SSH policy at the connection level»—. Dicho en claro: ya no se comprueba un nombre y se actúa como root; se actúa como quien pidió, y lo poco que necesita privilegio pasa por un único sitio que lo concede. Es la forma correcta de hacerlo, y ha hecho falta un fin de semana de trabajo para llegar.
Dentro de ese mismo diff hay tres cosas que no han salido en ningún titular y que a nosotros nos parecen más interesantes que el root:
- La grabación de la sesión podía no coincidir con lo que se ejecutó. Una confirmación explica que la cabecera de la grabación guardaba «una reconstrucción del comando analizada por el intérprete», cuando el comando se le pasa al shell del usuario tal cual, y que el analizador «descarta en silencio las comillas desparejadas». El arreglo es guardar el comando en bruto. Si archivas esas grabaciones para una auditoría o para un informe de incidente, eso no es un detalle: es la diferencia entre una prueba y un documento que creías prueba.
- La misma corrección ya se escribió en OpenSSH, hace diez años. Las notas de la versión 7.4 de OpenSSH, del 19 de diciembre de 2016, dicen esto: «When privilege separation is disabled, forwarded Unix-domain sockets would be created by sshd(8) with the privileges of 'root' instead of the authenticated user». Lo reportó Jann Horn, de Project Zero. El mismo fallo, en el mismo sitio. Y lo que OpenSSH puso en medio fue su monitor de separación de privilegios, que es exactamente adonde ha llegado Tailscale: el commit que vertebra la 1.104.4 se titula «route SSH forwarding through the privileged monitor». En el mismo diff va la otra reincidencia, la de las variables de entorno: la lista de prohibidas se amplió con
GCONV_PATH,LOCPATH,NLSPATH,HOSTALIASES,RES_OPTIONSy, en otra confirmación,GLIBC_TUNABLES, los clásicos para que un proceso privilegiado cargue un fichero que eliges tú. - Y las cosas pequeñas, que son las que delatan la prisa. Las claves privadas de host se escribían sin permisos 0600. Hicieron falta tres confirmaciones distintas para que la función que responde «¿esto es root?» entendiera lo mismo en todos los sitios donde se la llama; una se titula «treat numerically-zero uids as root in isRootUser».
Lo que esto no es
Tres acotaciones, porque el titular se presta a ir más lejos de lo que aguantan los hechos.
No es un atacante anónimo desde internet. Hace falta controlar ya un dispositivo al que tu política le permite conectarse al destino. Lo dice el VP de ingeniería de Tailscale, Mike Shaver: la mayoría de los problemas «concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled», y «it isn't the same as an unauthenticated attacker being able to connect to arbitrary machines, but the potential impact depends on how SSH access is configured». Nos parece una descripción honesta y la suscribimos. También es, exactamente, el escenario para el que se compra una malla zero trust. Lo que sí es, y conviene decirlo en el mismo párrafo: encadenable. En las pruebas de laboratorio el salto de máquina a máquina fue automático, por debajo del segundo por salto y sin intervención de nadie, hasta donde la política concediera SSH, y de ahí salieron tanto acceso de root en los destinos como claves con las que dar de alta dispositivos nuevos en la red. El radio de acción lo fija tu tabla de reglas, no la gravedad del boletín.
Tailscale SSH no viene activado. Hay que hacer dos cosas: ejecutar tailscale set --ssh en el destino y escribir una regla ssh en la política. Si no has hecho las dos, el 014 y el 015 no te tocan. El 016 y el 017 son de tailscale serve, que es otra función y también se activa aparte. Y Tailscale no recomienda que todo el mundo lo apague: «based on our current assessment, we're not recommending that everyone disable Tailscale SSH». Nosotros tampoco.
Y una opinión, etiquetada como tal. El informe que destapó esto se llama Tailworm, lo firma Erica Windisch (Cyberdione Labs) y recoge once hallazgos sobre Tailscale 1.104.2 y headscale 0.29.5, seis de severidad alta y cuatro de esas seis en Tailscale SSH. Se publicó el domingo 25, sin versión corregida disponible. La investigadora mandó el informe y la prueba de concepto al contacto de seguridad del fabricante antes de publicar; lo que no hizo fue esperar a que hubiera parche. El parche se etiquetó el martes por la noche. En medio quedaron dos días con el mapa publicado y sin versión que aplicar. Entendemos el argumento de quien publica, porque el reloj de un proveedor no corre solo; en una pieza que se ejecuta como root en servidores de empresas que no tienen a nadie mirando el feed un domingo, nosotros habríamos esperado. Dicho esto: la ventana ya pasó y la versión ya está.
Seis comprobaciones para esta semana
Ninguna cuesta dinero y cinco de las seis se pueden hacer antes de actualizar nada.
- 1. Saber en qué nodos está activado de verdad, no en cuáles crees. Un
tailscale status --jsonen cada nodo lo dice, y la consola del tailnet también. En un parque que lleva dos años creciendo, «lo activamos para aquella migración» es una frase que se oye mucho. - 2. Leer la sección ssh de la política entera, de principio a fin. Quién, hacia qué, y como qué usuario. Si una regla acaba concediendo el usuario root a un grupo amplio, ahí está tu radio de acción, y no lo ha creado el boletín de esta semana. Diez minutos.
- 3. Decidir si el reenvío hace falta. Si la respuesta es no —y en la mayoría de servidores lo es—, el propio TS-2026-014 publica la mitigación:
TS_SSH_DISABLE_FORWARDING=1. Se puede poner hoy, sin esperar a la versión nueva. - 4. Mirar tailscale serve aparte. TS-2026-016 no es SSH.
tailscale serve statuste dice qué hay publicado; si alguno apunta a un socket Unix, esa es otra puerta, con su propia lista de quién llega. - 5. Actualizar a 1.104.4 y comprobar la versión nodo a nodo. Los portátiles se actualizan solos; los servidores Linux van al ritmo del repositorio de la distribución y de la ventana de quien parchea. Un
tailscale versionnodo a nodo: la que importa es la del que tiene los sockets interesantes, no la del portátil desde el que miras. - 6. Ponerle número al checkPeriod. Si la regla no lo dice, son doce horas y valen para toda la red. Decidir doce horas está bien; heredarlas sin saberlo, no.
En corto
No hay nada exótico en el fallo: un proceso privilegiado comprobó un nombre y después actuó con sus propios permisos. Si has montado una malla para dejar de publicar puertos —y es una razón excelente para montarla—, has movido la decisión de quién entra en tus máquinas a una capa nueva. Esa capa también tiene versiones, también tiene fallos y también tiene una política que alguien escribió con prisa un martes. La malla no te ha quitado la decisión de encima; te la ha cambiado de sitio, y ahora hay que ir a mirarla donde está.
Dónde encaja esto en lo que hacemos
Cuando montamos un acceso zero trust no empezamos por la herramienta, sino por la tabla: quién tiene que alcanzar qué, con qué identidad, y qué pasa el día que un portátil de esa tabla esté en manos de otro. Esa tabla es la que decide si una semana como esta es un parche o es un incidente, y es independiente del producto que la implemente. La otra mitad es la de redes y comunicaciones: qué está publicado, por dónde entra el tráfico de administración y qué habría que tocar si mañana cambias de malla —porque las mallas se cambian, y la tabla no debería irse con ellas. Si te interesa la capa de debajo, ya escribimos sobre cuándo preferimos WireGuard y cuándo IPsec, que es el transporte sobre el que están construidas casi todas.
Fuentes (verificadas el 28 de octubre de 2026): boletines TS-2026-014, TS-2026-015, TS-2026-016 y TS-2026-017, los cuatro fechados el 26 de octubre de 2026 y corregidos en 1.104.4 — tailscale.com/security-bulletins. Etiqueta v1.104.4 creada el 27-10-2026 a las 23:01 UTC, ausencia de etiqueta 1.104.3 y las 42 confirmaciones entre 1.104.2 y 1.104.4 (ssh/tailssh, monitor privilegiado, reenvíos como el usuario de la sesión, comando en bruto en las grabaciones, denylist de variables de entorno, claves de host 0600, isRootUser) — repositorio público de Tailscale. Activación opcional de Tailscale SSH, modo de comprobación y periodo por defecto de 12 horas para toda la red — documentación de Tailscale SSH. Nota de seguridad de OpenSSH 7.4 (19-12-2016), reportada por Jann Horn (Project Zero), y llegada del reenvío de sockets Unix en OpenSSH 6.7 (06-10-2014) — notas de versión de OpenSSH. Declaraciones de Mike Shaver (VP de ingeniería de Tailscale), recuento de los once hallazgos del informe Tailworm de Erica Windisch (Cyberdione Labs) sobre Tailscale 1.104.2 y headscale 0.29.5, carácter encadenable de los fallos (salto automático por debajo del segundo, sin interacción, con robo de claves de alta de dispositivos) y cronología de la divulgación — SecurityWeek.
¿Sabrías decir hoy quién puede ser root en cada uno de tus servidores?
Si la respuesta está repartida entre una política de acceso, un fichero de sudoers y la memoria de alguien, esa es la conversación. La ponemos por escrito contigo, con la herramienta que ya tengas: quién llega a qué, con qué identidad y qué se cierra. Y si tu tabla ya está bien, te lo diremos y no te venderemos nada.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN