Saltar al contenido
hivek blog
Cuéntanos tu proyecto

Ciberseguridad

Cisco ISE tiene una falla CVSS 10.0 que decide quién entra a tu red: CISA fija el 19 de septiembre para parchar

CVE-2026-76460 permite a un atacante remoto sin credenciales tomar el sistema que autoriza qué dispositivos entran a la red interna. Qué versiones están afectadas, qué parche aplicar y por qué no es 'otro CVE de Cisco'.

Cisco ISE tiene una falla CVSS 10.0 que decide quién entra a tu red: CISA fija el 19 de septiembre para parchar

Cisco confirmó una falla de autenticación en Identity Services Engine (ISE) que permite a un atacante remoto, sin usuario ni contraseña, llegar a acceso root en el sistema que decide qué dispositivos entran a tu red interna. La falla ya se estaba explotando antes de que existiera el parche. CISA la sumó a su catálogo de vulnerabilidades explotadas activamente el 16 de septiembre de 2026 y fijó el 19 de septiembre como plazo de parcheo para agencias federales de Estados Unidos, según el aviso publicado en cisa.gov.

No es un firewall, es el portero de la red

Cisco ISE no filtra tráfico de internet hacia adentro, como haría un firewall perimetral. Es el sistema de Network Access Control (NAC) que se sienta en cada switch y punto de acceso WiFi con 802.1X: cuando un equipo se conecta, ISE decide si es un empleado autorizado, un invitado, una impresora o un dispositivo desconocido, y con qué privilegios entra. Gestiona políticas RADIUS y TACACS+, verifica el estado del dispositivo y aplica la segmentación de la red.

Eso cambia el cálculo de riesgo. Si un atacante compromete ISE, no rodea un perímetro: se convierte en la autoridad que aprueba su propio acceso. El resto de tu segmentación, VLANs, ACLs descargables, políticas de invitados, deja de importar porque el sistema que las aplica ya está de su lado.

Qué es la falla, en términos concretos

CVE-2026-76460 tiene CVSS 10.0, la puntuación máxima. El problema es un control de autenticación insuficiente en un endpoint de API: un atacante no autenticado envía una solicitud modificada, se salta por completo la interfaz de administración web y llega a ejecución de comandos con privilegios root, según el aviso técnico reportado por The Hacker News. Afecta a Cisco ISE y a ISE Passive Identity Connector (ISE-PIC) en las versiones 3.0 a 3.5, sin importar cómo esté configurado el dispositivo.

En el catálogo KEV, CISA la registra formalmente como "Cisco Identity Services Engine Incorrect Use of Privileged APIs Vulnerability". No es una falla teórica de laboratorio: Cisco la encontró mientras atendía un caso de soporte de un cliente, lo que significa que al menos una organización ya estaba comprometida antes de que existiera parche público, de acuerdo con el reporte de hwbusters. Es la definición estricta de día cero: explotación activa antes de la corrección.

Los parches, versión por versión

Cisco no ofrece workaround que cierre la falla. La única corrección real es actualizar. Estos son los parches disponibles, confirmados en el reporte de Qualys ThreatPROTECT y en SecurityWeek:

Versión instaladaParche que la corrige
3.1Patch 12
3.2Patch 11
3.3Patch 12
3.4Patch 7
3.5Patch 4

Si tu instalación corre la versión 3.0, ya está fuera de soporte: no hay parche para esa rama y la única ruta es migrar primero a una versión soportada y de ahí al parche correspondiente.

Donde actualizar de inmediato no sea posible (una migración de ISE en producción no se resuelve en una tarde), la mitigación que Cisco recomienda es restringir el acceso al dispositivo con listas de control de acceso a infraestructura (iACLs), permitiendo sólo el tráfico de administración y de plano de control estrictamente necesario. No es un sustituto del parche, es para ganar tiempo mientras lo aplicas.

Qué revisar en tu operación, en orden

  1. Confirma la versión exacta de tu ISE/ISE-PIC. No basta con saber que "está actualizado": necesitas el número de parche, no sólo la versión mayor.
  2. Revisa access.log en busca de nombres de usuario sospechosos, incluido el patrón dummyuser reportado en los indicadores de compromiso. Hazlo antes de aplicar el parche, no después: si hubo explotación, el parche no borra el rastro pero tampoco lo preserva indefinidamente.
  3. Ten presente que un atacante con acceso root puede borrar esos mismos logs. Si administras ISE en un despliegue distribuido, revisa cada nodo, no sólo el nodo de administración primario.
  4. Si no puedes parchar hoy, aplica las iACLs primero. Restringe qué IPs pueden siquiera alcanzar la interfaz de administración de ISE mientras coordinas la ventana de mantenimiento.
  5. Pregúntale a tu proveedor de red o al equipo que administra ISE cuál es su ventana de parcheo, y si ese calendario coincide con "cuando se pueda" o con una fecha concreta. Con explotación activa confirmada, "cuando se pueda" ya no es una respuesta aceptable.

Este mismo patrón, un sistema crítico con CVSS 10.0 y ventana de parcheo urgente, ya lo vimos con una falla crítica en SAP con CVSS 10.0 que obligó a revisar el parche de emergencia esa semana: el problema no es aplicar un parche, es saber con certeza en qué versión está cada sistema antes de que CISA lo obligue.

Dónde esta alerta no aplica

Si tu red no usa 802.1X ni NAC, si el control de acceso a tus switches y WiFi corporativo se hace de otra forma o simplemente no tienes Cisco ISE desplegado, esta falla no te toca directamente. No la confundas con vulnerabilidades de firewalls perimetrales o VPN, que son otro tipo de exposición con otra superficie de ataque: el zero-day de Chrome que exigió parchar antes del 18 de septiembre es un ejemplo de un riesgo completamente distinto, en el navegador de cada empleado, no en la infraestructura de red.

Tampoco es correcto asumir que basta con "aislar" el servidor de ISE de internet y dejarlo así. La mayoría de los compromisos de ISE no vienen de internet directamente: vienen de un atacante que ya tiene un punto de apoyo dentro de la red (una laptop comprometida, una VPN de proveedor) y desde ahí alcanza la interfaz de administración. Las iACLs ayudan, pero sólo si de verdad limitan el origen del tráfico permitido, no si simplemente quitan la exposición pública.

Y si tu equipo de TI te dice que "ya está en la lista para el próximo ciclo de mantenimiento", vale la pena preguntar de qué ciclo habla: con explotación activa confirmada por Cisco y por CISA, el ciclo normal de parcheo trimestral no es el que aplica aquí. El catálogo KEV de CISA existe justamente para separar "hay que parchar en algún momento" de "hay que parchar ya", y esta falla cae en la segunda categoría, como advirtió The Register al reportar el caso.

Llevar un inventario confiable de versiones, parches pendientes y ventanas de explotación activa en toda tu infraestructura no es un ejercicio que se resuelva revisando manualmente cada sistema cuando sale una alerta: es justo lo que resuelve una revisión de vulnerabilidades apoyada en IA, que prioriza y propone remediaciones sin esperar a que alguien lea el boletín de Cisco a tiempo.

Si administras Cisco ISE y todavía no confirmaste el número de parche exacto en cada nodo, ese es el primer correo que deberías mandar hoy, no el que sigue en tu lista de pendientes. Y si el inventario de versiones y parches de tu operación vive en la memoria de alguien, lo dejamos en un sistema que avisa solo.

Fuentes

Comentarios

→ Suscripción

Te avisamos cuando publicamos

Un correo por artículo, con los datos y las fuentes de cada caso. Automatización de procesos, IA aplicada y plataformas a la medida.

Un correo por artículo. Baja cuando quieras.