Introducción

Esta semana, Ivanti lanzó un alerta crítica sobre una vulnerabilidad en su solución EPMM (Endpoint Manager Mobile) que ya está siendo explotada en ataques reales como zero-day. Lo que hace distinto a CVE-2026-6973 no es solo su severidad (9.8 en CVSS), sino que requiere privilegios administrativos para ejecutar código remoto arbitrario en sistemas afectados. La urgencia se disparó cuando CISA incluyó este CVE en su catálogo Known Exploited Vulnerabilities y estableció un plazo de 4 días (hasta el domingo 10 de mayo) para que todas las agencias federales parcheen sus instancias.

El problema no es trivial: Ivanti EPMM es una plataforma ampliamente adoptada —más de 40.000 clientes en 100 países— que gestiona dispositivos móviles empresariales. Según datos de Shadowserver, actualmente hay más de 800 instancias expuestas en Internet, aunque no hay claridad sobre cuántas ya fueron comprometidas. Lo más preocupante es que el vector de ataque no es trivial de explotar, pero una vez que un atacante logra credenciales administrativas, la explotación es directa y silenciosa.

Qué ocurrió

El jueves 6 de mayo, Ivanti publicó un advisory oficial detallando CVE-2026-6973, una vulnerabilidad de ejecución de código arbitrario en versiones 12.8.0.0 y anteriores de Ivanti EPMM. La explotación requiere:

  1. Acceso previo con privilegios administrativos (Admin rights).
  2. Interacción del usuario (login en la interfaz administrativa).

El ataque se ejecuta mediante una vulnerabilidad en el componente de autenticación web, específicamente en el manejo de parámetros en solicitudes HTTP POST a endpoints como /mifs/jsp/admin/authentication/login.jsp. Un atacante con credenciales válidas puede inyectar comandos en campos como user o password, permitiendo la ejecución remota de código en el servidor con permisos del usuario que corre el servicio (generalmente root o ivanti).

Ivanti confirmó que, al momento de la disclosure, solo había evidencia de explotación limitada en el campo, pero no descartó que grupos APT (Advanced Persistent Threat) ya estén explotando esta falla en campañas dirigidas. Lo que sí es claro es que este CVE no afecta a Ivanti Neurons for MDM (su solución cloud) ni a otros productos como Ivanti Sentry o Ivanti EPM.

Este no es el primer incidente grave en Ivanti EPMM en 2025:

  • Enero 2025: CVE-2026-1281 y CVE-2026-1340 (ambas críticas, CVSS 9.1 y 9.8 respectivamente) explotadas como zero-days. Ivanti recomendó rotar credenciales en clientes afectados.
  • Abril 2025: CISA ordenó parchear CVE-2026-1340 en 4 días para agencias federales.

La repetición de estos incidentes sugiere un patrón de fallas críticas en componentes críticos de la solución, especialmente en su módulo de autenticación y manejo de sesiones.

Impacto para DevOps, Infraestructura, Cloud y Seguridad

Para equipos de Seguridad (SOC, CISO, Red Team)

  • Riesgo de explotación: Aunque el vector requiere credenciales administrativas, en entornos donde hubo explotación previa de CVE-2026-1281 o CVE-2026-1340, el riesgo de explotación de CVE-2026-6973 aumenta significativamente. Ivanti advirtió que si los clientes rotaron credenciales en enero, el riesgo se reduce.
  • Superficie de ataque: Más de 800 instancias expuestas en Internet (datos de Shadowserver). Esto incluye entornos on-premises y cloud híbridos mal configurados.
  • Impacto en la cadena de suministro: Ivanti EPMM es usado por sectores críticos (gobierno, salud, educación). Una explotación exitosa podría llevar a movimiento lateral en redes empresariales.

Para equipos de Infraestructura y Cloud

  • Entornos afectados: Solo versiones 12.8.0.0 y anteriores de Ivanti EPMM on-premises. Las versiones cloud (Ivanti Neurons for MDM) no están afectadas.
  • Complejidad de parcheo: El parche requiere reinstalar el appliance con las versiones 12.6.1.1, 12.7.0.1 o 12.8.0.1. No hay parche para versiones anteriores.
  • Downtime: El proceso de actualización puede requerir reinicio del servicio, lo que impacta en la disponibilidad de la gestión de dispositivos móviles.

Para equipos de DevOps y SRE

  • Integración con pipelines: Si EPMM se despliega como appliance virtual (OVA, VMDK), el proceso de actualización debe automatizarse en CI/CD para evitar retrasos.
  • Logging y monitoreo: El CVE explotado deja rastros en logs de autenticación (/var/log/tomcat/catalina.out). Se recomienda configurar alertas en SIEM para intentos de inyección en endpoints /mifs/jsp/admin/*.
  • Backup previo: Siempre realizar un backup completo de la configuración y base de datos del appliance antes de aplicar el parche.

Detalles técnicos

Versiones afectadas y parches disponibles

Versión afectadaParche disponibleCVSSDetalle
EPMM 12.8.0.0 y anteriores12.6.1.1, 12.7.0.1, 12.8.0.19.8Ejecución de código remoto con credenciales Admin
### Vector de ataque y PoC (Concepto de Prueba)

El ataque explotado sigue este flujo:

  1. Acceso inicial: El atacante obtiene credenciales administrativas (vía phishing, creds leaked, o explotación de CVE-2026-1281/CVE-2026-1340).
  2. Inyección: Mediante una solicitud HTTP POST a /mifs/jsp/admin/authentication/login.jsp, el atacante envía payloads en campos como:
   POST /mifs/jsp/admin/authentication/login.jsp HTTP/1.1
   Host: <IP_EPMM>
   Content-Type: application/x-www-form-urlencoded

   user=<PAYLOAD>&password=<PAYLOAD>&loginButton=Login
   

Donde <PAYLOAD> puede ser un comando como:

   user=admin'); DROP TABLE users; --&password=dummy
   
  1. Ejecución: El servidor procesa el payload en el contexto del usuario root, permitiendo:
– Lectura de archivos sensibles (/etc/shadow, archivos de configuración).

– Ejecución de comandos del sistema (id, whoami, curl <C2>).

– Persistencia mediante creación de usuarios o backdoors en servicios.

Componentes críticos involucrados

  • Autenticación web: Módulo mifs (Mobile Infrastructure Framework) en Apache Tomcat.
  • Base de datos: Uso de H2 Database (versión embebida) para almacenar credenciales, lo que añade riesgo de inyección SQL en versiones no parcheadas.
  • Sistema operativo: El appliance corre sobre CentOS 7.x (versión no especificada por Ivanti, pero típicamente vulnerable a CVEs como CVE-2024-4577).

Relación con otros CVEs recientes

  • CVE-2026-1281 y CVE-2026-1340: Ambos permitían ejecución de código sin autenticación (CVSS 9.1 y 9.8). Su explotación previa sugiere que grupos atacantes ya tienen acceso a credenciales o métodos para obtenerlas.
  • CVE-2026-6973: Requiere autenticación, pero una vez obtenida, la explotación es más simple y silenciosa que sus predecesores.

Qué deberían hacer los administradores y equipos técnicos

1. Verificar versión y exposición

Ejecutar estos comandos en el appliance para confirmar la versión:

# En el appliance EPMM (acceso SSH o consola)
cat /opt/ivanti/version.txt
# O via interfaz web:
https://<EPMM_IP>/mifs/about.jsp

Si la versión es 12.8.0.0 o anterior, el sistema está afectado.

Para verificar si el appliance está expuesto en Internet:

# Desde un equipo con nmap
nmap -p 443,8443 --script http-title <IP_EPMM>

Si responde con un título como Ivanti EPMM Admin Portal, está expuesto.

2. Aplicar parche urgente (paso a paso)

Ivanti exige reinstalar el appliance con una versión parcheada. No hay parche incremental.

Opción A: Actualización vía ISO (recomendada)

  1. Descargar la ISO correcta desde el portal de Ivanti:
EPMM 12.6.1.1: Enlace directo

EPMM 12.7.0.1: Enlace directo

EPMM 12.8.0.1: Enlace directo

  1. Montar la ISO en el appliance y ejecutar:
   sudo /opt/ivanti/upgrade.sh --iso /dev/cdrom
   
  1. Reiniciar el servicio:
   sudo systemctl restart tomcat
   

Opción B: Reinstalación limpia (si hay corrupción)

  1. Hacer backup de:
   /opt/ivanti/conf/
   /opt/ivanti/data/
   /var/lib/pgsql/
   
  1. Descargar la OVA/VMDK de la versión parcheada desde el portal de Ivanti.
  2. Importar en VMware ESXi o Hyper-V y configurar redes/ips.
  3. Restaurar configuración desde el backup.

3. Rotar credenciales y auditoría de cuentas

Ivanti recomienda:

  1. Rotar todas las credenciales administrativas (Admin, API keys, credenciales de integración con AD/LDAP).
   # Ejemplo para cambiar contraseña de Admin
   /opt/ivanti/bin/epmmcli.sh --user admin --password <NUEVA_PASSWORD> --set-password
   
  1. Auditar cuentas con privilegios:
   # Listar usuarios con rol Admin
   SELECT username FROM users WHERE role = 'Admin';
   
  1. Deshabilitar cuentas inactivas o con privilegios excesivos.

4. Monitoreo y detección

Configurar reglas en SIEM (Splunk, ELK, QRadar) para detectar:

  • Intentos de acceso a /mifs/jsp/admin/* con payloads sospechosos.
  • Logs de autenticación fallidos seguidos de comandos como id, whoami, curl.
  • Solicitudes POST con longitud anormal en campos user o password.

Ejemplo de regla en Splunk:

index=ivanti sourcetype="access_combined" uri_path="/mifs/jsp/admin/authentication/login.jsp"
| stats count by src_ip, user_agent
| where count > 5

5. Segmentación y hardening

Si no es posible parchear de inmediato:

  1. Bloquear acceso a la interfaz administrativa desde Internet:
   # En el firewall perimetral
   iptables -A INPUT -p tcp --dport 443 -s <IP_ADMIN> -j ACCEPT
   iptables -A INPUT -p tcp --dport 443 -j DROP
   
  1. Limitar acceso por VPN o jump host:
   # Ejemplo en firewall pfSense
   pass in proto tcp from { <VPN_POOL> } to { <EPMM_IP> } port { 443 8443 } keep state label "Ivanti EPMM Admin"
   
  1. Habilitar autenticación multifactor (MFA) en la interfaz de EPMM (si está disponible en la versión).

Conclusión

CVE-2026-6973 es un recordatorio de que las vulnerabilidades críticas en soluciones de gestión de dispositivos móviles no son excepcionales, sino recurrentes. La combinación de:

  • Explotación como zero-day (aunque con requisitos de acceso).
  • Impacto en más de 40.000 organizaciones globales.
  • Exposición masiva de instancias on-premises (más de 800 en Internet).

… hace que este CVE sea un punto de entrada ideal para grupos APT que busquen escalar privilegios o moverse lateralmente en redes empresariales.

La respuesta debe ser inmediata y estructurada:

  1. Parchear en 4 días (como exige CISA).
  2. Rotar credenciales y auditar cuentas con privilegios.
  3. Segmentar y monitorear el acceso a la interfaz administrativa.

No subestimar el riesgo: Ivanti ya tuvo dos zero-days en EPMM en 2025, y este patrón sugiere fallas de diseño en componentes críticos que podrían reaparecer. La prioridad es actuar antes de que un atacante aproveche esta ventana de exposición.

Fuentes

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *