🛡 VULNERABILIDADES 🛡

Vulnerabilidades no parcheadas en Tailscale SSH podrían permitir que un dispositivo comprometido alcance root en otros servidores.

⏰26 de octubre de 2026🛡CyberObservatorio

Idioma

◢ VULNERABILIDADES ◣

Vulnerabilidades no parcheadas en Tailscale SSH podrían permitir que un dispositivo comprometido alcance root en otros servidores.

⟫ 25/10/2026 ⟫ info@thehackernews.com (The Hacker News)

Fuente: The Hacker News

**Vulnerabilidad en Tailscale: Un Dispositivo Comprometido Puede Dar Acceso Root a Otros Servidores**

La ciberseguridad se ha convertido en un aspecto crítico para empresas y usuarios individuales en un mundo donde las amenazas digitales son cada vez más sofisticadas. Recientemente, un investigador de seguridad ha revelado una vulnerabilidad en Tailscale, una popular herramienta que permite crear redes privadas seguras. Esta vulnerabilidad no solo pone en riesgo a los dispositivos individuales, sino que también puede llevar a un acceso root no autorizado a otros servidores dentro de la misma red. Este hallazgo, publicado por Erica Windisch de Cyberdione Labs el 25 de octubre, ha despertado la preocupación entre administradores de sistemas y usuarios que dependen de la seguridad de sus redes.

El ataque en cuestión requiere que se cumplan dos condiciones fundamentales: que Tailscale SSH esté configurado para permitir el reenvío de puertos y que un atacante ya controle al menos un dispositivo dentro de la red, el cual tiene permiso para conectarse al objetivo. La naturaleza de esta vulnerabilidad radica en cómo Tailscale gestiona las conexiones SSH. A diferencia de un servidor SSH convencional, que verifica la contraseña o clave del usuario que se conecta, Tailscale identifica el dispositivo en sí, y una única regla de acceso determina si dicho dispositivo puede abrir una sesión SSH hacia un objetivo específico.

Windisch llevó a cabo sus pruebas utilizando Tailscale en su versión 1.104.2 y headscale en la versión 0.29.5, un servidor autohospedado que algunas redes utilizan como alternativa al servicio alojado por la compañía. Durante tres días, Windisch documentó en un laboratorio cómo un dispositivo comprometido podría usarse para obtener acceso root a otros dispositivos en la red, lo que representa un grave riesgo de seguridad. A la fecha de la publicación, Tailscale no había emitido ningún boletín de seguridad, identificador CVE o versión corregida para mitigar esta vulnerabilidad.

La respuesta de Tailscale no se hizo esperar. Mike Shaver, vicepresidente de ingeniería de la compañía, indicó en un hilo de Reddit que Tailscale había recibido el informe y que ya estaban revisando las mismas áreas junto a especialistas en seguridad externos. Sin embargo, Shaver aclaró que la compañía aún estaba evaluando qué configuraciones se veían afectadas y que no recomendaban desactivar Tailscale SSH de manera general.

La metodología del ataque es inquietante. El atacante primero necesita establecer un punto de entrada en un dispositivo, lo cual puede lograrse a través de diversas técnicas comunes, como aplicaciones web vulnerables, paquetes de software envenenados, phishing o credenciales de inicio de sesión robadas. Una vez que el atacante tiene acceso a un dispositivo, puede aprovechar la configuración de Tailscale SSH para escalar sus privilegios sin necesidad de contraseñas o claves robadas. Esto convierte a la vulnerabilidad en una preocupación seria para cualquier organización que utilice Tailscale.

El informe detalla cómo Windisch demostró el problema en varias etapas. Utilizando el reenvío de puertos SSH estándar, una sesión ordinaria permitió al proceso Tailscale con privilegios de root conectarse a un socket del sistema que, por diseño, solo debería ser accesible para el usuario root. Esto llevó a que el atacante pudiera leer el archivo de contraseñas del sistema casi de inmediato, sin necesidad de derechos de administrador.

En pruebas adicionales, Windisch también mostró que un socket de propiedad root podía ser reemplazado por el del atacante, lo que habilitaba la ejecución de comandos root directamente contra ciertos servicios. En una tercera variante del ataque, se logró eludir una verificación de seguridad que limitaba los archivos a los que se podía acceder mediante el reenvío, aprovechando una carrera entre las verificaciones del sistema y el uso de la ruta del archivo. Este último método permitió capturar una clave utilizada para inscribir nuevos dispositivos, que luego fue utilizada para añadir la máquina del atacante a la red como un servidor de confianza.

El impacto de esta vulnerabilidad es potencialmente devastador. Windisch describió el resultado general como "wormable", lo que implica que un dispositivo comprometido puede propagarse a todos los dispositivos que las reglas de acceso permitan, sin necesidad de contraseñas, claves robadas o intervención del usuario, en menos de un segundo por paso. En el laboratorio, este proceso se realizó a una velocidad sorprendente, aunque se debe aclarar que estos resultados fueron observados en un entorno controlado y no necesariamente reflejan el comportamiento en redes reales.

El informe también destaca que dos elementos limitaron la propagación del ataque: las reglas de acceso escritas como pares de origen a destino, que detuvieron la expansión en sí mismas, y las claves de dispositivo vinculadas a hardware como un Módulo de Plataforma Segura (TPM) o un Secure Enclave. Algunos investigadores han cuestionado públicamente la descripción de "wormable", mientras que otros han calificado el hallazgo de acceso root como serio y preocupante.

El problema del SSH es solo uno de los 11 hallazgos en el informe, que también cubre conectores de aplicaciones de Tailscale, su función de servidor y el relay DERP utilizado entre dispositivos. Windisch indicó que la escalada de privilegios en SSH "es preocupante", pero que el hallazgo relacionado con los conectores de aplicaciones "puede ser más impactante para algunas organizaciones", dado que permite a un usuario autorizado enviar tráfico a destinos que el equipo de seguridad nunca aprobó.

Los hallazgos presentados en el informe de Windisch no han sido replicados públicamente por otros investigadores, y Tailscale no ha confirmado las afirmaciones técnicas específicas. Windisch ha mencionado que el código de prueba de concepto detrás de los hallazgos no es público y que solo lo compartió con el contacto de seguridad de Tailscale. Además, Windisch ha calificado la divulgación como "reportada pero no coordinada", lo que ha suscitado críticas en algunos círculos por no haber comunicado primero los problemas a Tailscale antes de hacerlos públicos.

En respuesta a las preguntas de The Hacker News, Windisch aclaró que efectivamente había proporcionado a Tailscale una copia del informe y del código de prueba de concepto antes de la publicación pública, enviándolos a su contacto de seguridad el sábado anterior. También había expresado preocupaciones sobre la arquitectura de Tailscale con el consejero delegado de la compañía anteriormente, y había publicado un hash de archivo, aconsejando a los usuarios que desactivaran Tailscale SSH.

Este informe se suma a una serie de problemas en la misma área de Tailscale. En 2026, la compañía corrigió varias fallas en Tailscale SSH y en el manejo de sockets del servidor, incluyendo una en la que el reenvío de sockets Unix SSH podía alcanzar un socket privilegiado, en la versión 1.98.9.

Dado que no hay un parche disponible, las medidas a tomar se centran en los cambios en cómo se configuran Tailscale SSH y características relacionadas. El informe y las recomendaciones de Tailscale coinciden en la mayoría de ellas. Se aconseja revisar las reglas de acceso de Tailscale SSH, redactándolas como pares de origen a destino que nombren un dispositivo y un objetivo, eliminando reglas amplias que concedan acceso por identidad o etiqueta. Desactivar el reenvío de puertos SSH donde sea posible es crucial, y en la versión headscale 0.29.5 no se puede desactivar, por lo que se debe tratar cada concesión de SSH allí como si otorgara acceso root al objetivo.

Además, se recomienda eliminar permisos de conectores de aplicaciones de dispositivos que no los necesiten y desactivar cualquier reenvío de "tailscale serve" que apunte a un socket Unix. Activar la caducidad de claves de nodo también es una medida preventiva importante, para que una clave de dispositivo robada no permanezca válida indefinidamente. Si un dispositivo es comprometido, es esencial eliminarlo en el plano de control, ya que reimaging de la máquina no revoca las claves que un atacante ya pudo haber copiado.

Por último, Tailscale sugiere habilitar el modo de verificación de SSH, que añade un paso de inicio de sesión antes de que comience una sesión, así como activar las actualizaciones automáticas. Sin embargo, el modo de verificación no soluciona la escalada de privilegios; solo añade una barrera adicional ante ella. Con el incremento constante de las amenazas cibernéticas, es fundamental que tanto las empresas como los usuarios individuales mantengan una vigilancia proactiva sobre sus redes y dispositivos para protegerse contra ataques emergentes como el descubierto en Tailscale.

◢ VULNERABILIDADES ◣

Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers

⟫ 25/10/2026 ⟫ info@thehackernews.com (The Hacker News)

Source: The Hacker News

A single hacked device on a Tailscale network can be used to gain root access to other servers it can reach, according to a security researcher who published the findings this week. The attack requires two things: Tailscale SSH set up to allow port forwarding, and an attacker who already controls one device that the network's access rules permit to connect to the target. The findings were published on October 25 in a report calledTailwormby Erica Windisch of Cyberdione Labs. Windisch tested Tailscale version 1.104.2 and headscale version 0.29.5, the self-hosted server some networks use to run Tailscale instead of the company's hosted service, over three days in a lab. The report describes tests on that software, not attacks against real networks. As of publication, Tailscale had issued nosecurity bulletin, no CVE identifier, and no fixed version. Tailscale has responded in public. Mike Shaver, the company's vice president of engineering,wrote on Redditthat Tailscale had received the report, had already been looking at the same areas with outside security specialists, and had found issues it is working to fix. Shaver said the company is still working out which setups are affected, and that it is "not recommending that everyone disable Tailscale SSH." Tailscale SSH does not work like a normal SSH server. Rather than checking a connecting user's password or key, it identifies the device, and a single access rule decides whether that device may open an SSH session to a target. Because of this, the attack needs no stolen passwords or keys. It needs a foothold on one device first, which the report says an attacker can get the usual ways: a vulnerable web application, a poisoned software package, phishing, or stolen login details. Tailscale does not create that first foothold. How much an administrator can do about it depends on where the network is run. On Tailscale's hosted service, forwarding can be switched off per rule. On headscale version 0.29.5, forwarding cannot be turned off at all. The report says every SSH grant there should therefore be treated as giving root on the target. In the lab, Windisch showed the problem in stages. Using standard SSH port forwarding, an ordinary session caused the root-level Tailscale process to connect to a system socket that only root should access, and the test gained root and read the system password file almost immediately, without administrator rights. A second method replaced a root-owned socket with the attacker's, allowing direct root command execution against certain services. A third method defeated a safety check meant to limit which files forwarding can access by racing the system between when it checks a file path and when it uses it. That chain went further in the lab, the report says: it captured a key used to enroll new devices and used the key to join an attacker's own machine to the network as a trusted server. That last step worked from start to finish only on networks where Tailscale's Tailnet Lock feature was not enabled. On networks that do, the needed secrets were captured in transit, but the final step was not completed. Windisch describes the overall result as "wormable." In the lab, one compromised device could spread to every device that the access rules allow, with no passwords, no stolen keys, and no user action, in under a second per step. In the report's words, "the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed." That spread was measured in a lab, not seen on real networks. The report names two things that held it back: access rules written as single source-to-destination pairs, which stopped the spread on their own, and device keys tied to hardware such as a TPM or Secure Enclave. Some researchers who read the report have publicly questioned the "wormable" description, while others have called the root-access finding serious. The SSH problem is one of 11 findings in the report, which also covers Tailscale's app connectors, its serve feature, the DERP relay used between devices, and headscale. Windisch told The Hacker News that the SSH privilege escalation "is worrying," but that the app connector finding "may be more impactful to some organizations." The app connector finding, in an experimental feature called conn25, lets a permitted user send traffic to destinations the security team never approved, including a cloud provider's metadata service, which can hand out server credentials. All of the findings rest on Windisch's report alone. No other researcher has publicly reproduced them, and Tailscale has not confirmed the specific technical claims. Windisch said the proof-of-concept code behind the findings is not public, and that she provided it only to Tailscale's security contact. Windisch has described the disclosure as "reported but not coordinated," writing as muchon Ycombinator HN, and at least one commenter there called publishing without first reporting to Tailscale irresponsible. In response to questions from The Hacker News, Windisch said she had in fact given Tailscale a copy of the report and the proof-of-concept code before the public post, sending them to the company's security contact on the Saturday beforehand. She said she had also raised concerns about Tailscale's architecture with the company's chief executive earlier, and had publicly posted a file hash and advised users to disable Tailscale SSH. The report is the latest in a run of problems in the same part of Tailscale. Earlier in 2026, the company fixed several Tailscale SSH and server socket-handling flaws, including one whereSSH Unix socket forwarding could reach a privileged socket, in version 1.98.9. Because there is no patch, the available steps are changes to how Tailscale SSH and related features are set up. The report and Tailscale's own advice overlap on most of them. Review your Tailscale SSH access rules. Write them as single source-to-destination pairs that name one device and one target, and remove broad rules that grant access by identity or tag. The report calls per-pair rules the one control that stopped the spread in testing. Turn off SSH port forwarding where you can. On Tailscale's hosted service this is a per-rule setting. On headscale version 0.29.5 it cannot be turned off, so treat every SSH grant there as giving root on the target. Remove app connector permissions from devices that do not need them. Remove any tailscale serve forward that points at a Unix socket. Turn on node-key expiry, so a stolen device key does not stay valid forever. If a device is compromised, delete it at the control plane. Reimaging the machine does not revoke keys an attacker may have already copied off it. Tailscale also suggests enabling SSH check mode, which adds a login step before a session starts, and enabling automatic updates. Check mode does not fix the privilege escalation. It only adds another barrier in front of it.

𝐗 Twitter f Facebook ☎ WhatsApp ✈ Telegram

← VOLVER A CIBERSEGURIDAD