Cisco ISE sufre un fallo 10.0 explotado: actualizar es la única mitigación

25 de septiembre de 2026 a las 10:00|Autor: Equipo editorial de QUASA|5 lectura mínima| 1

El aviso final publicado por Cisco el 16 de septiembre de 2026 detalla que CVE-2026-76460 es una vulnerabilidad CVSS 10.0 explotada activamente. Afecta a Cisco Identity Services Engine (ISE) y Cisco ISE Passive Identity Connector (ISE-PIC), cualquiera que sea su configuración, y no dispone de una solución provisional que corrija el defecto.

La información publicada por The Register el 17 de septiembre corroboró que un atacante remoto sin autenticar puede aprovechar el fallo para ejecutar comandos con privilegios de root. La respuesta operativa tiene dos partes inseparables: instalar una versión corregida en todos los nodos y buscar indicios de una intrusión anterior.

Qué instalaciones están expuestas

La vulnerabilidad se encuentra en el control de autenticación de un endpoint de API. Una solicitud preparada permite eludir la interfaz de administración web y obtener acceso no autorizado al dispositivo, sin credenciales ni interacción de un usuario.

El alcance independiente de la configuración elimina una posible vía de descarte: no basta con comprobar si una función opcional está activa. Si el despliegue contiene ISE o ISE-PIC en una versión afectada, debe considerarse vulnerable aunque su configuración sea distinta de la de otros entornos.

Restringir la administración desde Internet puede reducir las oportunidades de ataque, pero no cambia el estado del software. Una instalación aislada mediante segmentación o listas de control continúa necesitando la actualización porque el código vulnerable permanece presente.

Árbol de decisión por producto y versión

La comprobación comienza con un inventario de cada nodo: producto, rama instalada y nivel de parche. La alerta del Centro Canadiense de Ciberseguridad del 17 de septiembre recoge las primeras versiones corregidas y señala que CVE-2026-76460 fue incorporada al catálogo de vulnerabilidades explotadas de CISA.

ISE o ISE-PIC 3.1: instalar como mínimo 3.1 Patch 12.
ISE o ISE-PIC 3.2: instalar como mínimo 3.2 Patch 11.
ISE o ISE-PIC 3.3: instalar como mínimo 3.3 Patch 12.
ISE o ISE-PIC 3.4: instalar como mínimo 3.4 Patch 7.
ISE o ISE-PIC 3.5: instalar como mínimo 3.5 Patch 4.
ISE 3.0 o una rama anterior: migrar a una versión compatible que contenga la corrección.

Coincidir con la rama de una versión corregida no es suficiente si falta el parche correspondiente. En un despliegue distribuido, la decisión se aplica nodo por nodo; actualizar únicamente el nodo principal dejaría el resto de la instalación expuesto.

Antes de cambiar de versión conviene verificar la memoria disponible y la compatibilidad del hardware y de la configuración con la versión de destino. Esa validación forma parte del despliegue seguro de la actualización, pero no sustituye la corrección ni altera la urgencia derivada de la explotación activa.

La iACL solo reduce temporalmente la exposición

No existe un workaround capaz de corregir CVE-2026-76460. Como contención transitoria puede aplicarse una lista de control de acceso de infraestructura, o iACL, que permita únicamente el tráfico imprescindible dirigido a los planos de administración y control del dispositivo.

La medida reduce las rutas desde las que podría intentarse una explotación remota, pero depende de que todos los caminos de acceso estén cubiertos y no modifica el endpoint vulnerable. Por eso actualizar es la única forma de remediar el fallo; la iACL sirve para contener la exposición mientras se instala el parche, no para declarar segura una versión afectada.

Parchear no erradica una intrusión previa

La actualización impide futuras explotaciones de esta vulnerabilidad, pero no elimina cuentas, comandos o cambios que un atacante pudiera haber introducido antes. Corregir el software y responder a un posible compromiso son tareas diferentes.

La revisión debe incluir ise-kong/access.log en cada nodo y buscar nombres de usuario sospechosos. Para ampliar el periodo examinado pueden recopilarse paquetes de soporte con los registros de depuración y revisar los archivos históricos de acceso de la pasarela de API.

Los registros locales no bastan para descartar un incidente porque los privilegios de root permiten ocultar o borrar evidencias. También deben contrastarse los registros de red y firewall conservados fuera del dispositivo, con atención a cargas inesperadas iniciadas desde ISE hacia direcciones externas y descargas procedentes de direcciones maliciosas.

Si aparecen indicios de explotación, instalar el parche no cierra el incidente. Los nodos sospechosos deben reconstruirse con una imagen limpia y, cuando sea necesario, restaurarse desde una copia de seguridad fiable; después habrá que determinar qué credenciales, integraciones y sistemas estuvieron al alcance del nodo comprometido.

El alcance de los ataques sigue sin conocerse

No se han divulgado el número de organizaciones afectadas, la identidad de los atacantes, la duración de la actividad ni las acciones realizadas después del acceso inicial. Esa falta de información impide medir públicamente la campaña, pero no cambia la exposición de las versiones vulnerables.

El despliegue solo puede considerarse técnicamente remediado cuando todos sus nodos ejecutan una versión corregida. Para descartar o contener un compromiso anterior hace falta además revisar la actividad registrada y reconstruir cualquier nodo con señales sospechosas.