--- title: "Tailworm pone en revisión Tailscale SSH: qué hacer mientras no hay parche" description: "El informe Tailworm describe 11 fallos en Tailscale y headscale que, en laboratorio, llevaron de un equipo comprometido a root en otros nodos. No hay parche: estas son las medidas provisionales." url: https://revistacloud.com/tailworm-tailscale-ssh-que-hacer-sin-parche/ date: 2026-10-26 modified: 2026-10-26 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/10/tailworm-tailscale-ssh-que-hacer-sin-parche.png categories: ["Noticias", "Seguridad"] tags: ["ciberseguridad", "Docker", "Kubernetes", "linux", "open source", "root", "ssh", "VPN", "vulnerabilidad", "Zero Trust"] type: post lang: es --- # Tailworm pone en revisión Tailscale SSH: qué hacer mientras no hay parche **Los equipos que usan Tailscale para dar acceso SSH a sus servidores tienen deberes esta semana: el informe Tailworm, publicado el 25 de octubre de 2026 por Erica Windisch, de Cyberdione Labs, describe 11 fallos en Tailscale y headscale que, en un laboratorio, permitieron saltar de un equipo comprometido a root en otros nodos de la red sin contraseñas ni claves robadas.** Tailscale ha reconocido que está corrigiendo problemas en esas áreas, pero todavía no hay boletín, CVE ni versión parcheada. **Las claves de Tailworm para los equipos que usan Tailscale SSH en 20 segundos** - Tailworm recoge 11 fallos probados en Tailscale 1.104.2 y headscale 0.29.5. - El riesgo principal es el reenvío de sockets en Tailscale SSH, gestionado por un proceso que corre como root. - No hay parche ni CVE; Tailscale desaconseja desactivar SSH de forma general. - Las reglas por pares y las claves ligadas a hardware frenaron el ataque. Tailscale se ha extendido como alternativa a las VPN clásicas y a los bastiones SSH porque conecta máquinas sobre WireGuard con políticas de acceso centralizadas, y muchos equipos lo usan también para entrar a servidores de producción con Tailscale SSH. Esa comodidad es la que examina el informe. Los resultados proceden de pruebas en laboratorio de una sola investigadora y nadie los ha reproducido aún de forma independiente, así que conviene tratarlos como avisos serios, no como incidentes confirmados. ## Dónde está el problema El núcleo del informe es arquitectónico. El servidor SSH de Tailscale vive dentro de `tailscaled`, el demonio del cliente, que tiene privilegios de root. Cuando una regla permite reenviar puertos o sockets Unix, ese proceso privilegiado es el que abre o reemplaza los sockets, incluidos los que solo debería tocar root, como el de Docker. En las pruebas, un usuario con una sesión SSH normal llegó a root y leyó `/etc/shadow`, y otra variante del fallo ejecutó código como root a través de un demonio local. El resto de hallazgos amplía el alcance a otras funciones: los conectores de aplicaciones experimentales, que según el informe dejaban salir hacia los servicios de metadatos de la nube o de Kubernetes; `tailscale serve` y Funnel cuando apuntan a sockets Unix; el cliente de los repetidores DERP; y el servidor headscale, que también recibe un aviso de agotamiento de recursos. Ninguno es explotable desde internet sin más: el atacante necesita controlar ya un dispositivo de la red, algo que puede llegar por una aplicación vulnerable, una dependencia envenenada o un portátil infectado. Lo que preocupa a los administradores es la velocidad de propagación descrita. Cada nodo conoce la lista completa de sus pares, de modo que desde el primer equipo el atacante ve todos los destinos posibles, y la cadena del laboratorio avanzó en menos de un segundo por salto. Con Tailnet Lock activado, el último paso, que era inscribir un servidor falso en la red, falló, según The Hacker News. ## La respuesta de Tailscale y el debate sobre la divulgación Windisch asegura que envió el informe y la prueba de concepto al contacto de seguridad de Tailscale el sábado anterior a publicarlo, sin esperar a un proceso coordinado, y esa decisión ha sido criticada en foros como Hacker News. También hay investigadores que discuten que el ataque pueda calificarse de gusano, aunque coinciden en que la escalada a root es grave. Mike Shaver, vicepresidente de ingeniería de Tailscale, respondió en Reddit que la empresa ya revisaba esas áreas con especialistas externos y que trabaja en correcciones, aunque todavía determina qué configuraciones están expuestas. Su recomendación es revisar las políticas SSH, limitar quién puede reenviar puertos, activar el modo check y mantener las actualizaciones automáticas, no desactivar Tailscale SSH en todas partes. OpenSecurity detalla los 11 fallos y los boletines anteriores de Tailscale en [Tailworm: 11 fallos sin parche en Tailscale podrían dar root en otros servidores](https://www.opensecurity.es/tailworm-tailscale-ssh-fallos-root-sin-parche/). ## Lista de comprobación para equipos de sistemas Mientras llega el parche, el informe propone medidas que cualquier equipo puede revisar en una tarde: - Auditar las reglas SSH de la política y sustituir las amplias, por grupo o etiqueta, por concesiones de un origen a un destino. - Denegar el reenvío de puertos en cada regla. En headscale 0.29.5 esa opción no existe, así que cada permiso SSH debe tratarse como acceso de root. - Desactivar Tailscale SSH en las máquinas que no lo necesitan con `tailscale set --ssh=false`, pero solo después de comprobar que queda otra forma de entrar. - Eliminar los permisos de conectores de aplicaciones sin uso y los reenvíos de `serve` hacia sockets Unix. - Activar la caducidad de claves de nodo y, ante un equipo comprometido, borrarlo en el plano de control: reinstalarlo no invalida las claves ya copiadas. El caso recuerda que una red de confianza cero depende tanto de sus políticas como del software. La protección que mejor funcionó en el laboratorio no fue un parche, sino una regla de acceso estrecha. Para quien prefiera montar su propia red privada sin servicios de terceros, Revista Cloud explicó cómo [convertir un Linux en una VPN con WireGuard](https://revistacloud.com/convierte-un-linux-en-tu-propia-vpn-con-wireguard-por-0-euros-o-desde-5-e-mes/), aunque esa opción exige gestionar a mano lo que Tailscale automatiza. ## Preguntas frecuentes ### ¿Están parcheados los fallos de Tailworm? No. A 26 de octubre de 2026, Tailscale no había publicado boletín, CVE ni versión corregida, aunque afirma estar trabajando en correcciones. ### ¿Afecta Tailworm a headscale? Sí. El informe probó headscale 0.29.5, donde además no se puede desactivar el reenvío de puertos en las reglas SSH. ### ¿Puede explotarse desde internet? No directamente. La cadena SSH requiere que el atacante controle ya un dispositivo de la red Tailscale. ### ¿Qué conviene revisar primero? Las reglas SSH de la política: sustituir las concesiones amplias por pares origen-destino y denegar el reenvío de puertos. **Fuentes:** - [OpenSecurity: Tailworm, 11 fallos sin parche en Tailscale](https://www.opensecurity.es/tailworm-tailscale-ssh-fallos-root-sin-parche/) - [Cyber Security News: Tailscale SSH flaws could let hackers gain root access across servers](https://cybersecuritynews.com/tailscale-ssh-flaws/) - [The Hacker News: Unpatched Tailscale SSH flaws could let a hacked device reach root on other servers](https://thehackernews.com/2026/10/unpatched-tailscale-ssh-flaws-could-let.html) - [Tailworm: informe de Cyberdione Labs](https://www.tailworm.com/) - [Tailscale: documentación de Tailscale SSH](https://tailscale.com/docs/features/tailscale-ssh)