Bajada. CISA incorporó tres vulnerabilidades al catálogo Known Exploited Vulnerabilities (KEV): CVE-2026-1603 (Ivanti Endpoint Manager), CVE-2025-26399 (SolarWinds Web Help Desk) y CVE-2021-22054 (Omnissa Workspace ONE UEM). Aunque no todas son nuevas, su inclusión en KEV cambia la prioridad operativa para equipos de infraestructura, seguridad y DevOps.

Introducción

Para equipos SysAdmin y DevOps, el catálogo KEV de CISA funciona como una señal de priorización: no se trata solo de “vulnerabilidades graves”, sino de fallas que ya tienen evidencia de explotación en entornos reales. En la actualización del 9 de marzo de 2026, CISA añadió tres CVE que afectan componentes comunes en organizaciones medianas y grandes: gestión de endpoints (Ivanti EPM), service desk (SolarWinds WHD) y gestión de movilidad corporativa (Workspace ONE UEM).

El punto clave no es únicamente el CVSS, sino el tipo de activo comprometido. En los tres casos, hablamos de sistemas con alto privilegio operativo o con visibilidad transversal de usuarios, dispositivos y credenciales. Cuando una plataforma de ese tipo queda expuesta, el impacto potencial se amplifica: movimiento lateral, extracción de secretos, manipulación de inventario o pivot hacia sistemas críticos.

Qué ocurrió

La entrada al KEV incluye:

  • CVE-2026-1603 en Ivanti Endpoint Manager, descrita como bypass de autenticación con posible filtrado de credenciales almacenadas.
  • CVE-2025-26399 en SolarWinds Web Help Desk, asociada a deserialización de datos no confiables en AjaxProxy, con riesgo de ejecución remota de comandos.
  • CVE-2021-22054 en Omnissa (antes VMware) Workspace ONE UEM, una SSRF que puede exponer información sensible sin autenticación.

En términos de gobierno técnico, el mensaje de CISA es directo: estas fallas deben salir del backlog “normal” y entrar en el carril de remediación acelerada. Incluso en organizaciones no sujetas a mandatos federales de EE. UU., KEV suele utilizarse como insumo de priorización en comités de riesgo y ventanas de cambio.

Impacto para SysAdmin / DevOps

El impacto operativo varía según el rol de cada plataforma en la arquitectura:

  • Ivanti EPM: si existe exposición externa o segmentación débil, el bypass puede derivar en acceso a datos de autenticación útiles para escalar privilegios en administración de endpoints.
  • SolarWinds WHD: en muchos entornos está integrado con correo, AD/LDAP, APIs internas y activos de soporte remoto. Un vector RCE en mesa de ayuda puede transformarse en puerta de entrada a la red corporativa.
  • Workspace ONE UEM: la SSRF puede habilitar enumeración interna o acceso a metadatos/servicios internos, especialmente en despliegues híbridos con dependencias hacia servicios internos y cloud.

Para equipos DevOps y SRE, la principal preocupación es la continuidad del servicio durante el parcheo. Son plataformas que suelen operar en horario extendido y con dependencia de múltiples equipos (soporte, seguridad, workplace). Por eso, la estrategia no puede ser “aplicar update y rezar”: requiere validación previa, snapshot/backup verificado y plan de rollback probado.

Detalles técnicos

1) CVE-2026-1603 (Ivanti EPM). El vector reportado es bypass de autenticación mediante canal alternativo, con capacidad de exponer credenciales específicas almacenadas. Este tipo de falla es especialmente delicado en herramientas de gestión centralizada porque la superficie útil para el atacante no es solo el servidor afectado, sino el ecosistema de agentes y credenciales asociadas.

2) CVE-2025-26399 (SolarWinds WHD). Se describe como deserialización insegura en AjaxProxy. En términos prácticos, es una clase de vulnerabilidad históricamente asociada a RCE cuando se procesan objetos no confiables. Si el servidor WHD comparte host con otros servicios o tiene permisos amplios, el radio de impacto crece de forma significativa.

3) CVE-2021-22054 (Workspace ONE UEM). Aunque es una CVE más antigua, su presencia en KEV indica explotación observada. Las SSRF siguen siendo un vector efectivo para pivot interno: acceso a endpoints no expuestos públicamente, servicios de metadata en nube o APIs internas con confianza implícita.

Un aspecto relevante es la combinación de antigüedad + explotación activa. Que una CVE de 2021 vuelva a la agenda por KEV muestra un patrón persistente: sistemas sin parches completos, workarounds incompletos o activos “olvidados” en segmentos no críticos.

Qué deberían hacer los administradores

  1. Inventario inmediato (24h): identificar todas las instancias de Ivanti EPM, SolarWinds WHD y Workspace ONE UEM, incluyendo entornos de DR, laboratorios y nodos legacy.
  2. Priorización por exposición: primero sistemas con acceso desde Internet, VPN de terceros o rutas desde segmentos de usuarios no administrados.
  3. Parcheo y mitigación: aplicar versiones/correcciones recomendadas por fabricantes; si no hay ventana inmediata, implementar controles compensatorios (ACL, restricción por origen, reverse proxy con autenticación fuerte, segmentación temporal).
  4. Rotación de secretos: en especial donde exista riesgo de exposición de credenciales (EPM/WHD). Rotar cuentas de servicio, tokens API y credenciales embebidas en integraciones.
  5. Threat hunting focalizado: revisar logs HTTP, eventos de autenticación anómala, creación de cuentas administrativas, ejecuciones no esperadas del servicio y conexiones salientes inusuales.
  6. Validación post-remediación: confirmar versión efectiva, controles activos y ausencia de indicadores de compromiso. Documentar evidencia para auditoría y comités de riesgo.

Como práctica adicional, conviene incorporar un SLA KEV interno: por ejemplo, 72 horas para exposición externa y 7 días para exposición interna, con excepciones formales y fecha de vencimiento.

Conclusión

La actualización KEV del 9 de marzo no es un evento “informativo”: es una señal operativa. Ivanti EPM, SolarWinds WHD y Workspace ONE UEM son plataformas con alta capacidad de administración y, por lo tanto, con alto impacto potencial cuando se comprometen. Para equipos SysAdmin y DevOps, la respuesta efectiva combina velocidad de parcheo, reducción de superficie y verificación técnica posterior. En un contexto de explotación activa, diferir estas acciones suele salir más caro que programar una ventana de cambio controlada.

Fuentes

Por Gustavo

Deja una respuesta

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