critica research global

Exploit público para AnyDesk Linux otorga acceso root sin autenticación

La corrección llegó en junio camuflada como un simple arreglo de estabilidad, sin CVE ni aviso formal. El exploit publicado el 8 de octubre revela que cualquier host Linux sin actualizar expone control root a un atacante no autenticado.

·11 min de lectura ·Equipo Vantis
En 30 segundos
  • Un exploit funcional para AnyDesk Linux, publicado el 8 de octubre de 2026, permite a un atacante no autenticado ejecutar comandos como root mediante una conexión TCP directa al puerto 7070.
  • La falla —apodada AnyPwn— se corrigió en la versión 8.0.3 en junio de 2026, pero el changelog del fabricante la describió solo como 'corrección de un error que podía causar un cuelgue', sin CVE ni aviso de seguridad, lo que la dejó invisible para los procesos de parchado que priorizan por severidad publicada.
  • No hay reportes de explotación activa a la fecha de la nota de CSA, pero el código ya es público: cualquier organización con hosts Linux corriendo AnyDesk 8.0.2 o anterior, alcanzables desde una red no confiable, debe tratar esto como urgente.

Qué pasó

Este análisis parte de una nota de investigación de Cloud Security Alliance (CSA Labs) publicada el 11 de octubre de 2026, que a su vez se apoya principalmente en un reporte de The Hacker News.

Según esa cadena de fuentes, el equipo de seguridad V12 —usando un motor de revisión de código asistido por IA— encontró un desbordamiento de heap previo a autenticación en el manejador de paquetes de modo 5 del protocolo de sesión de AnyDesk para Linux. El mecanismo descrito: el servicio toma un largo de payload entregado por el peer remoto y le suma una cabecera de 16 bytes usando aritmética de 32 bits sin verificar desbordamiento. Un atacante que declara un largo de 0xFFFFFFF0 provoca que la suma se desborde a cero: el servicio reserva un buffer minúsculo pero sigue registrando el largo original, y las escrituras posteriores corren fuera de esa reserva.

Como en Linux el servicio de AnyDesk corre como root, un atacante que logra explotar ese desbordamiento obtiene ejecución de código con privilegios completos, sin necesidad de escalamiento posterior. El vector confirmado es una conexión TCP directa al puerto 7070, sin aprobación del usuario y sin autenticación. La nota de CSA aclara que existe una ruta teórica a través de servidores relay de AnyDesk, pero que no hay una cadena de explotación completa demostrada públicamente por esa vía; lo tratamos como no resuelto.

Línea de tiempo reportada:

El exploit publicado es, según la fuente, probabilístico: depende de que el diseño de memoria del heap ubique un objeto útil junto al buffer desbordado; si el diseño es desfavorable, el servicio simplemente cae. Los offsets del código público apuntan específicamente a la build 8.0.2, por lo que su uso confiable está limitado a esa versión sin adaptación adicional —una limitación que conviene leer como fricción, no como protección real. Windows y macOS no están afectados; el problema es específico de la build Linux.

Nota de rigor sobre el respaldo de la información: la propia nota de CSA advierte que los dos artículos secundarios que cita ([2] y [3]) en gran medida repiten el reporte original de The Hacker News ([1]), que a su vez reproduce el relato del equipo V12. No se trata de tres confirmaciones independientes, sino de una fuente primaria —el hallazgo de V12— difundida por tres medios. Mantenemos esa distinción al calificar la confianza del análisis.

Por qué importa acá

AnyDesk es una herramienta de soporte remoto ampliamente usada por mesas de ayuda, proveedores de servicios gestionados (MSP) y equipos de TI en Chile y la región, muchas veces instalada por fuera del software corporativo gestionado centralmente. Eso hace que el problema estructural que describe esta nota —parches que no se anuncian como de seguridad— sea más relevante que el bug puntual.

Evaluación (confianza media): es razonable asumir que existen hosts Linux en organizaciones chilenas corriendo versiones de AnyDesk anteriores a 8.0.3, porque el changelog de junio no generó ninguna señal en los flujos típicos de gestión de vulnerabilidades basados en CVE o boletines de proveedor. La alternativa que no podemos descartar es que la base instalada de AnyDesk Linux en Chile sea pequeña frente a las versiones Windows/macOS, mucho más comunes en entornos corporativos locales —en cuyo caso la exposición real sería baja. No tenemos datos de telemetría local que permitan afirmar una cifra, así que esto queda como hipótesis razonable, no como hecho.

Para organizaciones chilenas, el ángulo práctico tiene tres capas:

  1. Gestión de parches por CVE no es suficiente. Si tu proceso de priorización depende de boletines de seguridad o puntajes CVSS, este caso habría pasado directamente bajo el radar durante más de tres meses, incluso con el fix ya disponible.
  2. Deber de reporte bajo Ley 21.663. La vulnerabilidad en sí no genera una obligación de reporte. Si una entidad calificada como OIV sufre un incidente confirmado que explote esta falla, ahí sí aplicaría el deber de reportar a CSIRT Nacional/ANCI según el procedimiento vigente de la organización; no corresponde anticipar plazos específicos que esta fuente no entrega.
  3. Criterios de proveedores. El caso es un argumento concreto para exigir, en la gestión de proveedores críticos, que las correcciones de seguridad en memoria vengan con CVE y aviso formal — algo relevante también bajo el enfoque de gestión de riesgos de terceros que impulsan tanto la Ley 21.663 como estándares como ISO 27001.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

El punto de gobierno real aquí no es la falla técnica sino el proceso que la dejó pasar: un changelog que describe un bug de memoria como 'crash fix' no entrega ninguna señal a un programa de gestión de vulnerabilidades que prioriza por CVE o severidad de aviso. Cualquier organización que delegue el patch management íntegramente en feeds de CVE tiene este mismo punto ciego con otros proveedores, no solo con AnyDesk.

  • Incorporar en la política de gestión de proveedores críticos la exigencia de CVE y aviso formal para cualquier corrección de seguridad en memoria, y registrar los casos en que un proveedor no lo haga.
  • Revisar el proceso interno de priorización de parches para que herramientas de acceso remoto con privilegios se actualicen en un ciclo fijo, independiente de si existe CVE o severidad publicada.
  • Si se confirma explotación en un host de una entidad OIV, evaluar el deber de reporte a ANCI/CSIRT Nacional bajo la Ley 21.663 según el procedimiento vigente de la organización, sin asumir plazos no verificados en esta fuente.
ID IdentificarSi esto me toca, por donde me toca

Antes de cualquier control, hay que saber dónde vive AnyDesk en la organización, incluyendo las instalaciones que la TI central no sabe que existen.

  • Inventariar todos los hosts Linux con AnyDesk instalado, incluyendo los instalados por usuarios finales o equipos de soporte fuera de la gestión central de software.
  • Confirmar la versión exacta de AnyDesk en cada host; cualquier versión 8.0.2 o anterior se considera vulnerable.
  • Mapear qué hosts exponen TCP/7070 a internet y cuáles lo exponen solo en la red interna, incluyendo segmentos planos donde un compromiso lateral sería posible.
PR ProtegerComo evito que ocurra

La protección prioritaria es simple de enunciar y urgente de ejecutar: actualizar y reducir la superficie expuesta. El detalle priorizado está en proteger.controles.

  • Actualizar AnyDesk a 8.1.0 o superior en todos los hosts Linux identificados.
  • Bloquear el tráfico entrante a TCP/7070 desde redes no confiables en firewall de host y perimetral.
  • Preferir acceso remoto mediado por gateway/VPN con autenticación central en vez de conexiones directas a AnyDesk.

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Actualizar AnyDesk a 8.1.0 o superior en todos los hosts Linux identificados bajo MITRE ATT&CK M1051 CIS Controls v8 7.1 ISO 27001 A.8.8
P1 Bloquear/filtrar conexiones entrantes a TCP/7070 desde redes no confiables, en firewall de host y perimetral bajo MITRE ATT&CK M1037 CIS Controls v8 13.1 ISO 27001 A.8.20
P1 Inventariar instalaciones de AnyDesk no gestionadas centralmente (shadow IT) en hosts Linux medio MITRE ATT&CK M1047 CIS Controls v8 1.1 ISO 27001 A.5.9
P2 Migrar a acceso remoto mediado por gateway/VPN con autenticación central en lugar de conexiones directas a AnyDesk medio MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.20
P2 Agregar verificación de versión de AnyDesk como regla personalizada en el escáner de vulnerabilidades y en la línea base de configuración bajo MITRE ATT&CK M1016 CIS Controls v8 7.5 ISO 27001 A.8.9
P3 Exigir a proveedores de software crítico la publicación de CVE/avisos formales para correcciones de seguridad en memoria, como criterio de gestión de proveedores medio MITRE ATT&CK M1019 CIS Controls v8 15.1 ISO 27001 A.5.19

Los tres primeros controles cierran la exposición inmediata y deberían estar resueltos esta semana en cualquier organización con AnyDesk en Linux. Los siguientes tres son los que evitan que el próximo 'crash fix' de otro proveedor pase inadvertido de la misma forma.

DE DetectarComo me doy cuenta de que ya ocurrio

No existen firmas ni IOCs de red públicos para esta campaña —no es una campaña, es una vulnerabilidad con exploit público y sin explotación confirmada en el mundo real al momento de la nota de CSA—. La detección realista es conductual: buscar procesos hijos inesperados generados por el servicio de AnyDesk corriendo como root, y correlacionar caídas del servicio con intentos de conexión no habituales al puerto 7070, dado que el exploit es probabilístico y puede dejar crashes como rastro de intentos fallidos.

  • Desplegar la regla Sigma (y sus traducciones) para detectar procesos hijos inesperados generados por el servicio AnyDesk ejecutando como root.
  • Correlacionar eventos de crash del servicio AnyDesk con intentos de conexión a TCP/7070 desde orígenes no habituales.
  • Agregar la verificación de versión de AnyDesk como regla personalizada en el escáner de vulnerabilidades, ya que los feeds basados en CVE no detectan este caso.

Qué necesitas tener logueado

  • auditd en hosts Linux con AnyDesk instalado (eventos execve, relaciones padre-hijo de procesos)
  • logs de firewall/perímetro para tráfico entrante hacia TCP/7070
  • EDR con visibilidad de Linux (procesos, usuario efectivo, línea de comandos)
  • logs del propio servicio AnyDesk (ad_svc), incluyendo eventos de crash y reinicio

Indicadores de compromiso

OjoLos indicadores están defanged (hxxp, [.]) para evitar clics accidentales. El bloque de abajo los trae en crudo, listos para tu lista de bloqueo.
TipoIndicadorConfianzaNota
puerto 7070/tcp media CSA Labs research note / The Hacker News
version_vulnerable AnyDesk Linux 8[.]0[.]2 y versiones anteriores alta CSA Labs research note
blocklistIndicadores en crudo
7070/tcp
AnyDesk Linux 8.0.2 y versiones anteriores

Reglas y consultas de detección

sigmaPosible explotación AnyPwn: proceso hijo inesperado desde el servicio AnyDesk ejecutando como root (Linux)
title: Posible explotacion AnyPwn - proceso hijo inesperado desde AnyDesk como root
id: a47e1c3b-6f2d-4e81-9c3a-7b5d2f814e6a
status: experimental
description: Detecta procesos hijos no habituales generados por el servicio AnyDesk corriendo como root en Linux, consistente con explotacion exitosa de AnyPwn (desbordamiento de heap en el handler de paquetes mode-5).
references:
  - https://labs.cloudsecurityalliance.org/research/csa-research-note-anydesk-anypwn-silent-patch-exploit-202610/
author: Vantis
date: 2026-10-11
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains: 'anydesk'
  selection_root:
    User: 'root'
  filter_known:
    CommandLine|contains:
      - '/usr/bin/anydesk'
      - '--service'
  condition: selection_parent and selection_root and not filter_known
falsepositives:
  - Actualizaciones legitimas del servicio AnyDesk
  - Scripts de administracion/MSP que invocan utilidades auxiliares con privilegios
level: high
tags:
  - attack.initial_access
  - attack.t1190
Requiere: Host Linux con auditd habilitado y agente que capture eventos process_creation con relación padre-hijo (por ejemplo Wazuh, Elastic Agent o un EDR con soporte Linux).
wazuhProceso hijo root inesperado desde AnyDesk (Wazuh/auditd)
<rule id="100210" level="12">
  <if_group>audit_command</if_group>
  <field name="audit.exe" negate="yes">/usr/bin/anydesk</field>
  <field name="audit.ppid.comm">anydesk</field>
  <field name="audit.uid">0</field>
  <description>Posible explotacion AnyPwn: proceso hijo inesperado desde AnyDesk ejecutando como root</description>
  <group>anydesk,anypwn,t1190,initial_access</group>
</rule>
Requiere: Agente Wazuh con el módulo auditd activo en el host Linux y reglas de auditoría que registren execve con información de proceso padre.
splunkAnyPwn: hijo inesperado de proceso AnyDesk root
index=linux_auditd OR index=edr_linux sourcetype="linux:audit"
| search ParentProcessName="*anydesk*" User="root"
| regex CommandLine!="(?i)(/usr/bin/anydesk|anydesk --service)"
| table _time host ParentProcessName ProcessName CommandLine User
| sort - _time
Requiere: Índice con eventos de ejecución de procesos Linux (auditd vía Splunk UF o EDR) incluyendo campos ParentProcessName, ProcessName, CommandLine y User.
sentinel-kqlAnyPwn: hijo inesperado del proceso AnyDesk como root (Linux)
DeviceProcessEvents
| where InitiatingProcessFileName has "anydesk"
| where AccountName == "root"
| where not(ProcessCommandLine has_any ("--service", "/usr/bin/anydesk"))
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
Requiere: Microsoft Defender for Endpoint en Linux ingiriendo a Sentinel, con la tabla DeviceProcessEvents disponible.
Falsos positivos esperables

Actualizaciones legítimas de AnyDesk, scripts de administración o automatizaciones de MSP que invocan utilidades auxiliares desde el proceso de AnyDesk con privilegios, y herramientas de monitoreo que inspeccionan el proceso del servicio. Ajustar la lista de exclusión (filter_known) a los binarios y rutas legítimas de la organización antes de poner la regla en modo de alerta activa.

RS ResponderContencion y erradicacion

Si se detecta actividad sospechosa en un host con AnyDesk vulnerable, el tratamiento debe ser el de un compromiso root confirmado, no el de una alerta a validar con calma.

  • Aislar de la red el host afectado y detener el servicio AnyDesk (ad_svc) de inmediato.
  • Revisar procesos con propietario root iniciados después del evento, persistencia nueva (cron, unidades systemd, llaves SSH) y conexiones salientes no habituales.
  • Preservar logs de auditd y del servicio AnyDesk antes de reiniciar o reinstalar, para análisis forense posterior.
  • Rotar credenciales y llaves accesibles desde el host comprometido, dado que el acceso obtenido es root completo.
RC RecuperarVolver a operar y no repetirlo

Dado que el acceso obtenido es root sin restricciones, la recuperación debe privilegiar reconstruir por sobre solo parchar cuando hay sospecha de compromiso real.

  • Reinstalar o reconstruir el host desde una imagen confiable si se confirma compromiso, en vez de solo actualizar el software en el host potencialmente afectado.
  • Validar que la versión instalada sea 8.1.0 o superior antes de reconectar el host a la red de producción.
  • Actualizar el inventario de activos y el proceso de descubrimiento de software para que capture instalaciones de AnyDesk fuera de la gestión central, evitando que un caso similar vuelva a pasar inadvertido.

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado