Tailworm: escalada de privilegios a root en Tailscale SSH

Resumen

• El servidor integrado de Tailscale SSH se ejecuta dentro de tailscaled, un demonio que corre como root, y realiza operaciones de reenvío de sockets Unix —conexión, vinculación y eliminación— con las credenciales de root. Una sesión SSH autorizada puede aprovecharlo para acceder a sockets exclusivos de root: los investigadores demostraron ejecución de comandos como root mediante docker.sock, una shell root mediante el socket de control de systemd y la captura de las claves que incorporan dispositivos nuevos.
• La auditoría probó software publicado: el cliente Tailscale 1.104.2, headscale 0.29.5 y la biblioteca gliderssh integrada en Tailscale. Tailscale publicó correcciones en 1.104.4 el 27 de octubre y divulgó sus hallazgos y cuatro boletines de seguridad el 28 de octubre.
• Los investigadores califican seis de los once hallazgos como de gravedad alta, incluida la clase de reenvío de sockets. Los boletines TS-2026-014 a TS-2026-017 de Tailscale cubren los problemas confirmados de SSH y Serve; a 28 de octubre no enumeran identificadores CVE ni puntuaciones CVSS. La explotación solo se demostró en laboratorio: propagación automática medida, limitada por la política, en menos de un segundo por salto, sin contraseñas ni claves robadas. No se conocen ataques reales.
• Configure TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled y reinícielo ahora, reescriba las reglas SSH como permisos por pareja y actualice los clientes a 1.104.4 o posterior. Los hallazgos del servidor headscale siguen siendo independientes: actualizar los clientes Tailscale no corrige los problemas del servidor de control headscale.

El informe numera los hallazgos así; las gravedades corresponden a la evaluación de los investigadores:

La evaluación de Tailscale distingue los fallos del comportamiento previsto: los hallazgos 9 y 10 funcionan según su diseño, y el hallazgo 4 afecta a conn25 antes de producción, no a los conectores de aplicaciones estables.

¿Estoy afectado?

Escalada por reenvío de sockets en Tailscale SSH. En un cliente sin corregir, está afectado si se cumplen todas estas condiciones:

• Ejecuta el cliente Tailscale con Tailscale SSH habilitado en un nodo objetivo.
• Su política SSH permite que el usuario o dispositivo que se conecta alcance el objetivo con el reenvío habilitado, ya sea mediante una regla accept o una sesión check aprobada. headscale 0.29.5 concede reenvío en las sesiones aceptadas sin un interruptor de desactivación por regla.
• El dispositivo que se conecta está comprometido o el usuario que se conecta es un atacante: los hallazgos funcionan desde cuentas completamente sin privilegios y no requieren contraseñas, claves ni sudo en el objetivo.

Denegación de servicio del servidor de control headscale (hallazgo 6). Un endpoint de registro headscale 0.29.5 accesible desde Internet puede atacarse sin cuenta ni acceso SSH. Por separado, el informe requiere un usuario interno autenticado para agotar la memoria del DERP integrado; un relé hostil es el requisito previo del ataque al cuerpo de respuesta del cliente Tailscale.

Compruebe qué ejecuta y qué permite su política:

tailscale version                     # client version on every node
tailscale status                      # the peers this device can see
headscale version                     # self-hosted control server, if you run one
sudo systemctl show tailscaled --property=Environment   # is TS_SSH_DISABLE_FORWARDING set?

La auditoría informa de que los nodos podían enumerar pares de la tailnet en su entorno de pruebas. No confíe en que la política sea secreta: revise las reglas SSH en su archivo de políticas, en la consola de administración de Tailscale para despliegues SaaS o en el archivo de políticas de headscale, y cuente cuántas son reglas accept para toda una identidad o etiqueta en vez de para un dispositivo de origen y otro de destino concretos.

¿Cómo lo corrijo?

Actualice los clientes Tailscale a 1.104.4 o posterior. Mientras programa esa actualización, reduzca la exposición del reenvío y restrinja el acceso SSH; el endurecimiento del servidor de control headscale sigue siendo una tarea independiente.

1. Desactive el reenvío SSH salvo que exista una necesidad documentada. En el entorno del servicio tailscaled, configure:

sudo mkdir -p /etc/systemd/system/tailscaled.service.d &&
  printf '[Service]\nEnvironment=TS_SSH_DISABLE_FORWARDING=1\n' |
  sudo tee /etc/systemd/system/tailscaled.service.d/disable-forwarding.conf &&
  sudo systemctl daemon-reload &&
  sudo systemctl restart tailscaled

La actualización de Tailscale del 26 de octubre dice que esto «mitiga varios de los hallazgos más graves» sin desactivar Tailscale SSH por completo. En el plano de control SaaS también puede configurar como denegados los campos de reenvío por regla; headscale 0.29.5 no tiene un interruptor equivalente por regla. La configuración del entorno del servicio se aplica en cada cliente Tailscale.

1. Reescriba las reglas SSH como permisos por pareja: un origen específico a un destino específico, nunca reglas accept para toda una identidad o etiqueta, ni cuentas privilegiadas como destino; restringir SSH a cuentas sin privilegios solo aporta defensa en profundidad, ya que los hallazgos funcionan desde cuentas completamente sin privilegios.
2. Instale Tailscale 1.104.4 o posterior en cada cliente y verifique con tailscale version. La publicación de hallazgos y correcciones de Tailscale del 28 de octubre enlaza los boletines TS-2026-014 a TS-2026-017.
3. Para servidores headscale alojados por cuenta propia, aplique el endurecimiento del informe hasta que exista una versión corregida: MemoryMax de systemd, supervisión de reinicios, limitación de velocidad delante de los endpoints de registro y ninguna exposición a Internet abierto.
4. Si ejecuta tailscale serve, elimine cualquier reenvío TCP dirigido a un socket Unix (serve --tcp <port> unix:<path>).
5. Si prueba conn25 experimental, retire la capacidad a los clientes que no la necesitan, aplique NetworkPolicies de salida con denegación predeterminada a los espacios de nombres de los conectores en Kubernetes e imponga una lista de destinos permitidos en la capa del kernel de los hosts conectores; el informe incluye un script para ello. Tailscale afirma que los conectores de aplicaciones estables no están afectados.

¿Cuál es la causa raíz?

Las operaciones de reenvío de Tailscale SSH se ejecutan con las credenciales del demonio root, de modo que cada comprobación de rutas que intenta limitarlas es una carrera que la sesión sin privilegios puede ganar.

Dos decisiones de diseño se combinan en el problema. Primero, Tailscale SSH no realiza autenticación a nivel de usuario: la autenticación se completa con el método none, porque la capa WireGuard ya ha identificado el dispositivo, y la política evalúa esa identidad del dispositivo, no una credencial de usuario; por tanto, la sesión conserva toda la autorización del dispositivo durante su vida útil.

Segundo, el servidor SSH integrado reside en tailscaled, que se ejecuta como root, y su biblioteca gliderssh realiza como root las operaciones de reenvío de sockets Unix: conexión para ssh -L, vinculación y eliminación para ssh -R.

La biblioteca sí intenta limitar dónde puede terminar el reenvío. En streamlocal.go de tailscale/gliderssh, las funciones validateAndResolveSocketPath y validateAndResolveListenPath comprueban la ruta contra una lista de directorios permitidos antes de ejecutar la operación y resuelven los enlaces simbólicos, porque es el kernel, no el validador, quien realiza la conexión final:

// validateAndResolveSocketPath validates socketPath lexically, then resolves
// its symlinks and re-checks that the real destination is still within
// opts.AllowedDirectories and not excluded by opts.DeniedPrefixes. It returns
// the resolved path to dial.
//
// The lexical check alone is insufficient because the kernel connects to the
// symlink target: a symlink inside an allowed directory could otherwise
// redirect the connection to a socket outside it (e.g. a link in the user's
// home dir pointing at /var/run/docker.sock).

Tailscale 1.104.2 incorpora gliderssh en la versión v0.3.4-0.20260716005906-1a0f895faf28, según su go.mod, y la lista de permitidos abarca el directorio personal del usuario, /tmp y /run/user/<uid>. Pero la validación ocurre al comprobar la ruta, mientras que la eliminación, la vinculación y la conexión ocurren después, cuando el kernel vuelve a resolverla.

El hallazgo 3 muestra la brecha: un bucle de carrera con rename(2) dentro de la propia sesión SSH del atacante, medido en unos 170.000 cambios de estado de ruta por segundo, presenta una ruta inocua a la comprobación y cambia el directorio al objetivo antes de que el demonio root opere sobre él. La conclusión del informe en una línea: la lista de permitidos {home, /tmp, /run/user} «no es un límite de seguridad».

Esta clase tiene un precedente reconocido por CVE y una solución conocida. CVE-2025-14282 de Dropbear era el caso del lado de la conexión, corregido en 2025.89 mediante setuid() al usuario de la sesión antes de cualquier operación de reenvío, por lo que no se necesita comprobar rutas. OpenSSH es el contraejemplo claro auditado en el informe: su proceso hijo posterior a la autenticación reduce privilegios al usuario de la sesión antes del bucle del servidor, por lo que no hay fase de comprobación ni brecha entre comprobación y uso.

¿Cómo se explota?

La demostración más simple, el hallazgo 1, necesita una regla de política SSH que permita el reenvío local; muestra la conexión como root sin ninguna carrera. Los comandos proceden del kit de reproducción público del informe:

ssh -fNT -L /tmp/relay.sock:/tmp/docker.sock user@target   # dockerd at an allowlisted-dir socket
docker -H unix:///tmp/relay.sock run --rm -v /:/host busybox sh -c 'id; head -c 40 /host/etc/shadow'

La conexión la realiza tailscaled, por lo que las credenciales del par que ve el socket son las de root. El resultado verificado fue uid=0(root) junto con el contenido de /etc/shadow, sin sudo ni pertenencia al grupo Docker. Esta demostración utiliza el dockerd estándar del objetivo a través de tailscaled; no requiere un demonio implantado ni otra vulnerabilidad de dockerd. La cadena más potente, el hallazgo 3, explota la carrera entre comprobación y uso:

1. El atacante dispone de acceso inicial en cualquier dispositivo permitido por la política, obtenido mediante una aplicación web explotada, una dependencia maliciosa, un implante de phishing o credenciales de identidad robadas, y se conecta al objetivo por Tailscale SSH bajo una regla que permite reenvío.
2. Dentro de la sesión, ejecuta un bucle de carrera rename(2) sobre un directorio incluido en la lista de permitidos, cambiando su estado unas 170.000 veces por segundo, de modo que la comprobación léxica ve una ruta inocua y el kernel la vuelve a resolver hacia el objetivo al ejecutar la operación.
3. El demonio root elimina el socket activo propiedad de root en la ruta real, por ejemplo /run/docker.sock, el socket localapi de tailscaled o el socket de control de headscale, y vincula allí el puerto de escucha de reenvío del atacante.
4. El atacante mantiene la revinculación abierta durante 4 minutos o más, según se verificó, y actúa como intermediario en el servicio. Contra el socket localapi, el tráfico capturado incluía un POST /localapi/v0/start exacto byte a byte que contenía una authkey, la credencial que incorpora dispositivos nuevos.
5. El atacante utiliza la authkey capturada en un nodo temporal y lo incorpora a la tailnet bajo la identidad de la víctima: un nodo intruso que parece un servidor legítimo etiquetado, con rutas aprobadas automáticamente, demostrado de extremo a extremo en laboratorio.

Un hallazgo secundario amplía las operaciones disponibles: el control de eliminación y el chmod posterior a la escucha siguen la ruta léxica al usarse, por lo que la sesión que ejecuta la carrera puede hacer que root elimine archivos normales arbitrarios y cambie sus permisos a 0600; esto permite destrucción, aunque no modificación de contenido.

¿Cómo transcurre el ataque?

Un dispositivo comprometido con una regla SSH aprobada obtiene root en los servidores objetivo y después se convierte en un nodo persistente de la red, sin robo de contraseñas ni claves en ningún punto de la cadena.

¿Qué puede hacer un atacante?

La toma de control de sockets alcanza cualquier servicio privilegiado que use sockets Unix. El informe demostró lo siguiente, con pruebas conservadas:

• Ejecución de comandos como root mediante una carrera contra un dockerd estándar: una única conexión persistente que ganó la carrera completó la creación de un contenedor con / montado dentro mediante bind y la ejecución de comandos con uid 0.
• Una shell root mediante el socket de control de systemd: systemd autorizó conexiones con credenciales root a /run/systemd/private, y la reproducción de bytes D-Bus inició una unidad transitoria que produjo una shell inversa root, con entrega intermitente por la carrera. Las conexiones mediante carrera a un socket kubelet simulado también fueron aceptadas todas al presentar uid 0.
• Robo de credenciales de incorporación de dispositivos: la cadena desde la toma de control del socket hasta la incorporación convierte una revinculación en un nodo intruso con rutas aprobadas automáticamente, una persistencia que sobrevive a la reinstalación del host original, además de eliminación arbitraria de archivos de root y chmod 0600 forzado como destrucción de disponibilidad.
• Propagación por toda la flota: con una ruta SSH concedida por la política, el informe midió propagación automática a todos los dispositivos permitidos, sin contraseñas, claves robadas ni interacción del usuario, en menos de un segundo por salto. Se mantuvieron dos límites estructurales: los permisos de acceso por pareja detuvieron la propagación, y las credenciales de dispositivo vinculadas al hardware impidieron que el robo de identidad persistiera.
• Agotamiento de memoria del demonio root, hallazgo 5: la sucesión de cambios de ventana y adiciones ilimitadas al entorno asignó unos 536 MB en 7 segundos, que persistieron tras desconectarse; el fallo se hereda de gliderlabs/ssh v0.3.8 original.
• Validación de salida del conector de aplicaciones, hallazgo 4: conn25 experimental permite que un usuario con autorización ordinaria por aplicación elija destinos de salida arbitrarios a través del conector, incluidos metadatos de nube y servicios Kubernetes, porque el destino declarado por el cliente nunca se valida contra los backends configurados de la aplicación. Tailscale afirma que esto no afecta a los conectores estables.
• Denegación de servicio de headscale, hallazgo 6: la expulsión de entradas de la caché de registro sin autenticación puede bloquear la incorporación en toda la organización; el agotamiento de memoria del DERP integrado requiere un usuario interno autenticado. El subhallazgo del cliente Tailscale requiere un relé hostil.

Para el reenvío de sockets, las condiciones son un dispositivo autorizado o comprometido con acceso SSH permitido por la política y reenvío habilitado en un cliente sin corregir. headscale 0.29.5 concede reenvío sin un interruptor de desactivación por regla. El modo check, la reautenticación por navegador de Tailscale para SSH, no controla el reenvío: aprueba el establecimiento de la sesión, y los hallazgos de reenvío de sockets operan después durante toda la vida de esa sesión aprobada.

¿Por qué funciona la corrección?

Las correcciones de reenvío SSH de los hallazgos 1–3 ejecutan las operaciones de sockets como el usuario de la sesión, aplicando la separación de privilegios recomendada por el informe y ya utilizada en la corrección CVE-2025-14282 de Dropbear. Los hallazgos de Serve y agotamiento de recursos tienen correcciones independientes. Según la sección de respuesta del proyecto original del informe y los boletines de Tailscale:

• Hallazgos 1 a 3: el reenvío SSH se rediseñó con un monitor por conexión y procesos hijos sin privilegios con credenciales propias. La conexión, la vinculación y la eliminación de sockets reenviados se ejecutan ahora con las credenciales del usuario autenticado de la sesión, y las credenciales del par de la carga útil identifican a ese usuario en vez del demonio root. La revalidación léxica de rutas que derrotaba la carrera se eliminó en favor de los controles de acceso discrecional del kernel como límite.
• Hallazgo 5: los envíos de cambios de ventana en gliderssh no bloquean y conservan el último valor, y se limita la sucesión de cambios de entorno (PR #21945 y #21953; el mensaje del commit original reconoce las mediciones de la auditoría).
• Hallazgo 7: el reenvío TCP de serve al socket localapi se rechaza tanto al configurarlo como en cada conexión (PR #21966).
• Hallazgo 8: los destinos Unix de los backends del proxy HTTP de Serve se revalidan en cada conexión, sustituyendo la protección de enlaces simbólicos que solo se aplicaba al recargar la configuración. Tailscale identifica esta corrección en TS-2026-016, publicada en 1.104.4.
• Hallazgo 11: la gestión de capacidades pasa a un contexto por solicitud (PR #21931).
• Hallazgo 6 (cliente): el relé limita la lectura del cuerpo de respuesta (PR #21980).

Para el reenvío SSH, una vez que la conexión, la vinculación y la eliminación se ejecutan como el usuario de la sesión, las propias comprobaciones de permisos del kernel deciden qué puede tocar la sesión, y no hay brecha entre comprobación y uso porque no se necesita ninguna comprobación con privilegios elevados. Tailscale 1.104.4 publicó estas correcciones del cliente el 27 de octubre; el proveedor confirmó su disponibilidad el 28 de octubre. El informe probó headscale 0.29.5 y sigue enumerando sus correcciones del servidor como pendientes. Actualizar el cliente Tailscale no remedia esos hallazgos de headscale.

¿Cómo compruebo si me comprometieron?

No se conocen ataques reales. El informe ofrece estas pautas de detección para investigar sistemas sin corregir:

• Auditoría del ciclo de vida de sockets: reglas auditd sobre operaciones de eliminación, vinculación y chmod de sockets Unix en los directorios donde se permite el reenvío, /tmp, los directorios personales y /run/user, y en las propias rutas de sockets del agente, delimitadas por objeto según ruta y operación en vez de por nombre de llamada al sistema. Un socket con modo 0755 en una ruta que debería tener 0600 es una firma forense de una vinculación que ganó la carrera y cuyo chmod posterior a la escucha fue redirigido.
• Detección de ráfagas de renombrado: la carrera necesita bucles sostenidos de renombrado de directorios del orden de 100.000 por segundo, por lo que una vigilancia con inotify o audit y alertas de frecuencia sobre los directorios candidatos permite detectarla.
• Supervisión de incorporaciones y claves: alerte sobre la emisión o uso de authkeys fuera de las ventanas de cambios y sobre cualquier nodo que se incorpore con una clave nunca vista bajo una identidad etiquetada, y trate como incidente cualquier aviso de usuario sobre una solicitud de autenticación Tailscale no solicitada, ya que una conexión del atacante puede provocar la solicitud check. En headscale, supervise la memoria residente, la rotación de entradas de la caché de registro y la latencia de registro.

Si encuentra pruebas de compromiso, reinstalar no equivale a contener: la identidad de un nodo es material criptográfico almacenado en un archivo de estado, y un atacante con root puede haberlo copiado fuera del equipo, donde sigue siendo válido hasta que se elimine el dispositivo en el plano de control o caduquen sus claves. Elimine el dispositivo, rote todas las authkeys y credenciales accesibles desde el host afectado, y rote Tailnet Lock si se comprometió un nodo firmante.

Cronología

• 2026-10-22 a 2026-10-24: Cyberdione Labs prueba las versiones publicadas Tailscale 1.104.2, headscale 0.29.5 y la biblioteca gliderssh integrada; los hallazgos del conector afectan a conn25 experimental, previo a producción.
• 2026-10-25: se publica el informe Tailworm con once hallazgos y kits de reproducción; The Hacker News lo cubre ese mismo día.
• 2026-10-26: Tailscale publica «Tailscale SSH: actualización de la investigación y remediación», confirma una escalada de privilegios grave más allá del usuario local configurado y fija como objetivo un cliente corregido para finales del 27 de octubre, sujeto a pruebas. Las correcciones de los hallazgos 1 a 3 y 5 se incorporan a las ramas principales de tailscale y gliderssh.
• 2026-10-27: se integran las correcciones de los hallazgos 7, 11 y del componente relé del cliente (PR #21966, #21931, #21980); la revisión de la caché de registro de headscale, PR #3586, sigue pendiente. Tailscale etiqueta el cliente corregido como 1.104.4.
• 2026-10-27: este artículo.
• 2026-10-28: Tailscale publica sus hallazgos y correcciones con los boletines TS-2026-014 a TS-2026-017; este artículo se actualiza para reflejar la disponibilidad de 1.104.4 y el alcance pendiente.

Preguntas frecuentes

¿Tailscale está pidiendo a todos que desactiven Tailscale SSH?

No. La actualización de Tailscale del 26 de octubre dice que «no recomienda que todos desactiven Tailscale SSH», porque la explotación depende de los permisos concedidos al usuario o dispositivo que se conecta y de la configuración del sistema. Para los clientes sin corregir, las medidas provisionales de Tailscale son desactivar el reenvío, revisar las políticas de acceso SSH y restringir el acceso a sistemas sensibles. Su orientación del 28 de octubre es actualizar a 1.104.4 o posterior.

¿Me protege el modo check?

No. El modo check solo controla el establecimiento de la sesión; el reenvío de puertos ocurre dentro de una sesión establecida y aprobada, y todos los hallazgos de reenvío de sockets se aplican durante su vida útil. El informe también midió que, en el plano de control SaaS, una comprobación satisfactoria se extiende a todos los destinos en modo check hasta que caduca la ventana de aprobación, por lo que una autorización rutinaria del propio usuario puede habilitar destinos que interesan al atacante.

¿Tailnet Lock detiene la incorporación del nodo intruso?

Eleva la dificultad, pero no fue una barrera completa en laboratorio. Con Tailnet Lock desactivado, la opción predeterminada, la cadena completa desde la authkey capturada hasta un nodo intruso conectado funcionó de extremo a extremo; con el bloqueo habilitado, se capturaron en tránsito el secreto de desactivación y el material de claves firmantes, aunque no se ejecutó una desactivación real. Ante un nodo firmante comprometido, rote el bloqueo en lugar de limitarse a limpiar. El informe documenta kits de reproducción para cada hallazgo y no se conoce ningún exploit funcional contra un despliegue real.

¿Se puede explotar desde Internet?

Los hallazgos SSH, directamente no: el atacante necesita acceso inicial a un dispositivo ya permitido por la política o una cuenta autorizada. En el laboratorio del informe, la malla convirtió un acceso inicial en acceso privilegiado a los destinos permitidos por la política a velocidad de máquina. Los hallazgos de headscale son distintos: un usuario de Internet sin autenticación puede interrumpir la incorporación de dispositivos mediante un endpoint de registro accesible desde Internet, por lo que no debe exponerlo.

¿Qué versión del cliente corrige estos problemas?

Actualice a Tailscale 1.104.4 o posterior y confirme con tailscale version en cada nodo. La publicación de hallazgos y correcciones de Tailscale del 28 de octubre y los boletines TS-2026-014 a TS-2026-017 confirman la versión. Hasta actualizar cada cliente, desactive el reenvío SSH y utilice permisos SSH por pareja. Las correcciones del servidor de control headscale siguen siendo independientes.

Analice su superficie de ataque externa con Ostorlab para detectar servidores de control headscale expuestos a Internet y otra infraestructura alojada por cuenta propia que no debería ser accesible desde Internet abierto.

Referencias

• Cyberdione Labs, «Tailworm: informe de evaluación de seguridad, Tailscale v1.104.2 y headscale v0.29.5», publicado el 25 de octubre de 2026, con los once hallazgos, reproducciones verificadas, mediciones de propagación como gusano y pautas de detección, y la matriz de mitigación actualizada el 28 de octubre: https://tailworm.com/ (consultado el 28 de octubre de 2026)
• Tailscale, «Tailscale SSH: actualización de la investigación y remediación», 26 de octubre de 2026, que confirma los hallazgos, la mitigación TS_SSH_DISABLE_FORWARDING=1 y el objetivo de un cliente corregido para finales del 27 de octubre: https://tailscale.com/ssh-investigation-update (consultado el 27 de octubre de 2026)
• Pull requests de corrección de tailscale/tailscale: #21941, #21942, #21943, #21944, #21945, #21953, #21959, #21963, #21966, #21931, #21980 (consultados el 28 de octubre de 2026)
• streamlocal.go de tailscale/gliderssh, funciones validateAndResolveSocketPath y validateAndResolveListenPath, la validación léxica seguida de resolución que derrota la carrera: https://github.com/tailscale/gliderssh/blob/master/streamlocal.go (consultado el 27 de octubre de 2026)
• go.mod de Tailscale 1.104.2, que fija gliderssh en v0.3.4-0.20260716005906-1a0f895faf28: https://github.com/tailscale/tailscale/blob/v1.104.2/go.mod (consultado el 27 de octubre de 2026)
• CVE-2025-14282 de Dropbear, el precedente de esta clase corregido en 2025.89 al establecer el uid de la sesión antes de cualquier solicitud de canal o global: https://nvd.nist.gov/vuln/detail/CVE-2025-14282 (referenciado en el informe Tailworm, consultado el 27 de octubre de 2026)
• Revisión de la caché de registro de headscale, PR #3586, que adopta control de admisión en vez de expulsión y cita el informe: https://github.com/juanfont/headscale/pull/3586 (referenciado en la respuesta del proyecto original a Tailworm, consultado el 27 de octubre de 2026)
• Cobertura de The Hacker News sobre los hallazgos Tailworm, 25 de octubre de 2026: https://thehackernews.com/2026/10/unpatched-tailscale-ssh-flaws-could-let.html (consultada el 27 de octubre de 2026)
• Publicación de Tailscale 1.104.4: https://github.com/tailscale/tailscale/releases/tag/v1.104.4; hallazgos y correcciones del proveedor, 28 de octubre de 2026: https://tailscale.com/blog/tailscale-ssh-findings-fixes; boletines de seguridad TS-2026-014 a TS-2026-017: https://tailscale.com/security-bulletins (consultados el 28 de octubre de 2026)