Ivanti Sentry: un RCE sin autenticación se explota masivamente a horas de su divulgación

Contexto del incidente

El 11 de junio de 2026, la CISA agregó CVE-2026-10520 a su catálogo Known Exploited Vulnerabilities (KEV) con un plazo de remediación que venció el 14 de junio, apenas tres días después. La vulnerabilidad afecta a Ivanti Sentry, el gateway de Ivanti que gestiona y cifra el tráfico entre dispositivos móviles corporativos y servicios de back-end como Microsoft Exchange, y recibió una calificación de CVSS 3.1 de 10.0 crítico (vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, CWE-78: OS Command Injection). Es el puntaje más alto posible: ejecución remota de código como root, sin autenticación y sin interacción del usuario.

El descubridor fue watchTowr Labs, que publicó su análisis técnico y un PoC funcional el mismo día del advisory de Ivanti, lo que aceleró el reloj de exposición para todas las organizaciones con appliances sin parchear. Horas más tarde, The Shadowserver Foundation reportó que 2 de las 19 instancias de Sentry accesibles desde Internet que monitoreaba ya estaban backdooreadas, y observó una oleada masiva de intentos de explotación contra la población más amplia de appliances. El propio Shadowserver tuiteó que, si no parchaste, lo más probable es que estés comprometido.

La vulnerabilidad reside en un endpoint de API que la mayoría de las implementaciones expone sin autenticación. Un atacante remoto puede inyectar comandos del sistema operativo que el appliance ejecuta con privilegios de root, lo que entrega control total sobre el dispositivo y todo el tráfico que pasa por él. A diferencia de un RCE tradicional, acá no hay credenciales válidas, MFA ni sandbox que valgan: alcanza con reachability de red al puerto de management para tomar el servidor.

El problema se agrava con un segundo CVE publicado en el mismo advisory: CVE-2026-10523, un bypass de autenticación que permite crear cuentas de administrador nuevas en el appliance. Encadenado con el RCE, el atacante primero obtiene root y después implanta un admin persistente que sobrevive a cualquier reinicio, parche o rotación de credenciales. Ivanti fue enfática en su advisory: hay que auditar las cuentas administrativas existentes antes de cerrar la ventana de remediación, porque parchear sin esa auditoría deja la puerta principal cerrada pero la ventana abierta.

Ivanti Sentry ocupa una posición particularmente sensible en la arquitectura: se ubica inline entre los dispositivos móviles de la organización y los servicios internos. Un atacante con root en Sentry puede interceptar, leer y potencialmente manipular cada mensaje de correo móvil y cada payload corporativo que pasa por el gateway. En organizaciones que enrutan Exchange, MDM, intranet móvil o apps internas a través de Sentry, el compromiso equivale a un MitM persistente sobre toda la comunicación móvil empresarial.

Un parche sin auditoría de cuentas es un cerrojo nuevo en una puerta con la ventana abierta. La remediación de este doble CVE exige dos acciones distintas: software actualizado y revisión forense de identidades.

¿Cómo proteger tu infraestructura?

1. Aplicar los parches sin demora

Las versiones afectadas son todas las anteriores a R10.5.2, R10.6.2 y R10.7.1. Si administrás Sentry, validar urgentemente la versión instalada y planificar la actualización fuera de horario si la operación lo permite. Las versiones EOL (anteriores a 10.5) no tienen parche y deben migrarse a una rama soportada. Las notas de release de Ivanti detallan los prerrequisitos; conviene revisarlas antes del upgrade para evitar ventanas de downtime innecesarias.

2. Auditar cuentas administrativas antes de cerrar la ventana

Abrir la consola de Sentry y revisar la lista completa de cuentas admin, no solo las activas. Buscar fechas de creación posteriores al 9 de junio, nombres que no respondan a usuarios conocidos, orígenes geográficos inconsistentes con la operación normal y cuentas con permisos elevados que no figuren en el inventario del equipo. Si encontrás algo, tratá al appliance como comprometido: rotar credenciales de integración, revisar la configuración de MDM, de directorios y de cualquier sistema al que Sentry se conecte.

3. Segmentar y restringir el acceso al management

Si la única razón por la que el puerto de management es accesible desde Internet es operativa, hoy es el día de repensarlo. Aplicar listas de IPs permitidas, mover el panel a una VLAN de administración y, donde sea posible, exponer Sentry únicamente a través de un reverse proxy con autenticación fuerte. El advisory de Ivanti aclara que el uso de mTLS con EPMM o HTTPS restringido vía Neurons for MDM hace inaccesible la superficie atacada, lo que reduce drásticamente el riesgo de un appliance que no pueda parchearse en el corto plazo.

4. Cazar señales de compromiso en appliances expuestos pre-patch

Para quienes tenían Sentry con el puerto de management expuesto a Internet antes del 9 de junio, la pregunta no es si fueron atacados, sino cuándo. Buscar: usuarios administradores creados fuera de proceso, cambios en binarios del sistema, tareas programadas nuevas, conexiones salientes hacia destinos no documentados, picos anómalos de errores 4xx/5xx en logs web previos a la fecha del parche. Shadowserver ofrece datos de IPs vulnerables en su feed "Vulnerable HTTP reporting" etiquetado cve-2026-10520, útil para confirmar si la propia organización aparece en sus mediciones.

Indicadores de compromiso (IoC)

La superficie observable es la siguiente:

• Producto afectado: Ivanti Sentry versiones 10.5.1, 10.6.1, 10.7.0 y todas las anteriores.
• Versiones seguras: R10.5.2, R10.6.2, R10.7.1.
• Endpoint vulnerable: API HTTP interna de Sentry, accesible por defecto en la interfaz de management.
• Mecanismo de persistencia conocido: CVE-2026-10523 (auth bypass) permite crear cuentas admin incluso después de aplicar el parche del RCE.
• Señales de ataque: cuentas administrativas nuevas con timestamp posterior al 9 de junio de 2026, archivos de configuración modificados, túneles SSH o reverse shells iniciados desde el appliance, procesos hijos sospechosos corriendo bajo el UID del servicio Sentry.
• Cadena de telemetría: monitorear tráfico saliente desde Sentry hacia destinos no incluidos en una baseline conocida; un gateway no debería iniciar conexiones outbound salvo hacia los servicios MDM y de telemetría documentados.
• PoC público: https://github.com/watchtowrlabs/watchTowr-vs-Ivanti-Sentry-RCE-CVE-2026-10520-CVE-2026-10523 (uso defensivo, fingerprinting y validación de parches).
• Advisory vendor: https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Sentry-CVE-2026-10520-CVE-2026-10523.

# Buscar cuentas admin sospechosas creadas después del 9 de junio
grep -E "admin|administrator" /var/log/sentry/audit.log 2>/dev/null \
  | awk '$1 >= "2026-06-09"' | sort -u

# Identificar procesos hijos inesperados del servicio Sentry
ps -eo pid,ppid,user,comm | awk '$2 == "<PID_SENTRY>" && $4 !~ /sentry|httpd/'

# Verificar la versión instalada (debe ser >= 10.5.2 / 10.6.2 / 10.7.1)
cat /opt/sentry/VERSION 2>/dev/null || cat /etc/sentry-release

# Buscar conexiones salientes no documentadas desde el appliance
ss -tnp state established '( dport != :443 and dport != :80 )' \
  | grep -vE 'mdm|eps|nps' | head