Un exploit público da acceso root en equipos Linux con AnyDesk 8.0.2

10.10.2026 4 min 8

Unos investigadores han publicado un exploit funcional para AnyDesk en Linux que ejecuta comandos como root en la máquina objetivo sin contraseña y antes de que nadie acepte la conexión. El exploit, llamado AnyPwn, apunta a AnyDesk 8.0.2 ejecutándose como servicio y llega hasta él por el puerto TCP 7070. AnyDesk corrigió el fallo en junio en la versión 8.0.3, pero el registro de cambios lo describía solo como "fixed a bug that could lead to a crash" ("corregido un error que podía provocar un cierre inesperado"), sin CVE ni aviso de seguridad, de modo que muchos administradores no tenían motivo para considerar urgente la actualización.

Qué hace el exploit

El error lo encontró Rick de Jager, de la empresa de seguridad V12, que publicó la prueba de concepto en GitHub el 8 de octubre. Se trata de un desbordamiento de montón en el código que gestiona los primeros paquetes de una sesión: AnyDesk confía en un campo de longitud enviado por el lado remoto antes de comprobarlo, el número se desborda y el programa copia datos del atacante más allá de un búfer diminuto. En Linux el servicio de AnyDesk normalmente se ejecuta como root, así que el código ejecutado de este modo obtiene el control total del equipo. No hace falta ningún clic ni aprobación de la persona que está frente a la pantalla.

El exploit público tiene límites. Se construyó para una compilación concreta de 8.0.2 en Linux de 64 bits, necesita una conexión directa al puerto 7070 y no funciona siempre: cuando la disposición de la memoria no coincide, lo que se bloquea es el servicio de AnyDesk. Los investigadores dicen que 8.0.1 podría contener el mismo fallo, pero no adaptaron el exploit a esa versión. AnyDesk afirma que el problema está "limited to direct connections on Linux (connections that do not go through our relays)" ("limitado a las conexiones directas en Linux, es decir, las que no pasan por nuestros relés") y que no afecta a Windows ni a macOS. Sin embargo, V12 asegura haber confirmado que el código vulnerable también es accesible a través de los servidores de relé de AnyDesk. No construyó un exploit completo para esa vía, de modo que sigue abierta la cuestión de si las conexiones por relé son explotables.

Por qué se pasó por alto el parche

Los equipos de seguridad suelen decidir qué parchear primero según los números CVE y los avisos de los fabricantes. Hasta el 9 de octubre este fallo no tenía ni lo uno ni lo otro, así que los escáneres y paneles de parches que dependen de los feeds de CVE no tenían nada que señalar. Un equipo Linux cuyo AnyDesk se actualizó por última vez antes de junio sigue ejecutando una versión para la que ya existe un exploit público. Según V12, el fabricante retiró de su web la compilación 8.0.2 después de que los investigadores publicaran un vídeo del ataque.

Revise sus equipos

  1. Averigüe la versión: ejecute anydesk --version. Cualquier versión anterior a la 8.0.3 debe actualizarse. La versión actual es la 8.1.0.
  2. Compruebe si el servicio está escuchando: sudo ss -ltnp | grep 7070. Una línea con anydesk indica que el puerto está abierto en ese equipo.
  3. Actualice mediante el gestor de paquetes o el repositorio de AnyDesk y reinicie después el servicio con sudo systemctl restart anydesk.
  4. Cierre el puerto 7070 a Internet en el cortafuegos del equipo, en el router y en cualquier grupo de seguridad de la nube. La solución es actualizar. Cerrar el puerto es una segunda barrera mientras siga abierta la duda sobre las conexiones por relé.
  5. Busque señales de alerta: cierres repetidos del servicio de AnyDesk, conexiones inesperadas al puerto 7070 y procesos iniciados por el servicio de AnyDesk que nadie lanzó.

Un servicio de escritorio remoto que escucha en Internet abierto es un riesgo incluso con todos los parches. Si solo se puede llegar a él mediante una VPN u otra red privada hacia la red de la oficina o del hogar, un fallo como este no se puede explotar desde Internet, solo lo puede hacer quien ya tenga acceso a esa red. Lo mismo ocurrió con el fallo SSH en los routers MikroTik. Nuestra guía de configuración de WireGuard explica cómo montar un túnel así en su propio servidor.

anydesklinuxvulnerabilidadciberseguridadvpn

Lee también