Un fallo de autenticación de la API de Cisco ISE abre una vía remota al acceso root

Cisco ha publicado correcciones de emergencia para una vulnerabilidad crítica de día cero que afecta a Identity Services Engine y a ISE Passive Identity Connector. El fallo ya está siendo explotado y los ataques exitosos pueden permitir ejecutar comandos con privilegios root.

Identificada como CVE-2026-76460, la vulnerabilidad tiene la puntuación CVSS máxima: 10,0. Afecta a Cisco ISE e ISE-PIC con independencia de cómo estén configurados los productos.

Cisco publicó su aviso a las 16:00 GMT del 16 de septiembre de 2026. Ese mismo día, CISA añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas y estableció el 19 de septiembre de 2026 como fecha límite para que las agencias federales estadounidenses aplicaran la corrección.

No existe una mitigación completa. Los administradores deben instalar la versión corregida correspondiente e investigar los dispositivos afectados en busca de indicios de explotación previa.

Una API de administración no aplica correctamente la autenticación

CVE-2026-76460 existe porque un endpoint de la API de ISE no aplica controles de autenticación adecuados. Cisco relaciona el problema con CWE-648, que describe el uso incorrecto de API privilegiadas.

Un atacante remoto no autenticado puede enviar una solicitud especialmente diseñada a un dispositivo afectado. La solicitud puede eludir las protecciones de la interfaz de administración web y proporcionar acceso no autorizado al sistema.

La vulnerabilidad no requiere credenciales robadas, una cuenta existente ni la intervención de un administrador. También se considera de baja complejidad, lo que significa que su explotación no depende de condiciones de carrera inusuales ni de requisitos previos difíciles de cumplir.

Su vector CVSS 3.1 completo es:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:X/RL:X/RC:X

La clasificación de cambio de alcance refleja consecuencias que se extienden más allá del componente inicialmente vulnerable. La confidencialidad, la integridad y la disponibilidad están consideradas altamente afectadas.

Cisco advierte de que la explotación puede permitir ejecutar comandos como root. Con ese nivel de privilegios, un intruso podría modificar el dispositivo, interrumpir su funcionamiento o manipular las pruebas almacenadas localmente. El acceso root también hace menos fiable el análisis posterior al incidente, ya que un atacante podría eliminar registros o esconder rastros de la intrusión.

Cisco identifica internamente la vulnerabilidad como el error CSCww39530. El identificador de su aviso es cisco-sa-ISE-ABP-VNSW7Tn5.

Todas las ramas compatibles de ISE requieren un parche específico

Los productos vulnerables son:

• Cisco Identity Services Engine
• Cisco ISE Passive Identity Connector

Cisco afirma que la exposición no depende de la configuración del dispositivo. Por tanto, las organizaciones no deben asumir que un modo de implementación inusual, una función desactivada u otro ajuste local elimina el riesgo.

La versión corregida necesaria depende de la rama de software instalada:

Versión instalada de Cisco ISE o ISE-PIC	Primera versión que incluye la corrección
3.1	3.1 Patch 12
3.2	3.2 Patch 11
3.3	3.3 Patch 12
3.4	3.4 Patch 7
3.5	3.5 Patch 4

Los administradores que ejecuten una de estas ramas deben instalar el parche indicado o una versión corregida posterior disponible para esa rama.

Cisco ISE Software Release 3.0 ha llegado al fin del mantenimiento de software. No cuenta con un parche correctivo indicado, por lo que las organizaciones que aún lo utilicen deben migrar a una versión compatible que incluya la corrección.

El aviso de seguridad del fabricante es la referencia oficial para consultar la correspondencia entre versiones. Las organizaciones con implementaciones distribuidas deben inventariar todos los nodos, en lugar de comprobar únicamente el sistema principal de administración.

Los ataques activos dejan un plazo federal de tres días para aplicar la corrección

El Product Security Incident Response Team de Cisco ha confirmado que la vulnerabilidad está siendo explotada activamente. La empresa descubrió el fallo mientras resolvía un caso de soporte del Cisco Technical Assistance Center, no durante una evaluación interna programada.

No se ha identificado a ningún actor de amenazas. Cisco no ha relacionado la actividad con una organización delictiva, una operación patrocinada por un Estado ni un grupo de ransomware concreto, y la información disponible no describe los objetivos de los atacantes.

CISA añadió CVE-2026-76460 a su catálogo de vulnerabilidades explotadas conocidas el 16 de septiembre de 2026. Las agencias federales deben completar la corrección exigida antes del 19 de septiembre de 2026.

La entrada de KEV exige a las agencias aplicar las medidas de Cisco y cumplir la BOD 26-04, «Prioritizing Security Updates Based on Risk», además de los requisitos de triaje forense de CISA. Las disposiciones aplicables de la BOD 26-04 también abarcan los servicios en la nube. Si no existe ninguna medida de mitigación disponible, CISA indica a las partes afectadas que interrumpan el uso del producto.

El triaje forense es obligatorio de forma específica. Se desconoce si la vulnerabilidad se está utilizando en campañas de ransomware.

El breve plazo responde a una explotación observada, no a una vía de ataque meramente teórica. Los responsables de los activos también deben evaluar si cada dispositivo está expuesto a internet o puede alcanzarse desde redes desde las que un atacante podría enviar solicitudes a su plano de administración.

Las iACL pueden reducir la exposición, pero no eliminan el fallo

Cisco no ha identificado una medida de mitigación que resuelva por completo CVE-2026-76460. Instalar una versión corregida es la única medida de corrección indicada.

Mientras se aplican los parches, los administradores pueden implementar listas de control de acceso a la infraestructura, o iACL, para limitar el tráfico que llega al dispositivo afectado. Estos controles deben permitir únicamente las conexiones de administración y del plano de control necesarias desde sistemas y redes expresamente autorizados.

Esta medida puede reducir las rutas disponibles para un atacante remoto, especialmente cuando los servicios de administración eran accesibles de forma amplia. Sin embargo, no corrige la lógica de autenticación deficiente del endpoint de la API.

La prioridad debe centrarse en los sistemas expuestos a internet y en los dispositivos accesibles desde segmentos de red menos fiables. No obstante, estar ubicado en una red interna no demuestra por sí solo que un sistema sea seguro. Una estación de trabajo, un servidor o una cuenta de acceso remoto comprometidos podrían proporcionar al atacante la posición de red necesaria para alcanzar una interfaz de administración con restricciones insuficientes.

Las restricciones de red deben mantenerse después de aplicar el parche siempre que sea posible desde el punto de vista operativo. Proporcionan un límite adicional alrededor de un servicio de infraestructura con privilegios elevados, pero no deben considerarse un sustituto de la actualización de software.

Los equipos defensivos deben revisar los registros de todos los nodos

Cisco recomienda revisar los datos de access.log en busca de nombres de usuario y actividad de API sospechosos. En una implementación distribuida de ISE, los investigadores deben examinar todos los nodos, ya que las entradas relevantes podrían no aparecer en el sistema principal o central.

Cisco ofrece el siguiente ejemplo para buscar en el registro del gateway de API:

admin#show logging application ise-kong/access.log | include dummyuser

El valor dummyuser es un ejemplo, no un indicador de compromiso completo. Una coincidencia puede indicar actividad maliciosa, pero los investigadores deben validarla comparándola con las solicitudes circundantes, las direcciones de origen, las marcas de tiempo y el comportamiento administrativo esperado. También deben buscar otros nombres de usuario anómalos, en lugar de confiar únicamente en ese valor.

Es posible obtener registros adicionales del gateway de API recopilando un paquete de soporte con los registros de depuración incluidos. Cisco recomienda proteger el paquete mediante cifrado con clave compartida, descifrarlo en el entorno de investigación y examinar los archivos ubicados en:

./ise/logs/apigateway/access.log..gz

Las pruebas locales pueden estar incompletas. Dado que el fallo puede permitir potencialmente la ejecución de comandos con privilegios root, un atacante que haya tenido éxito podría modificar registros, eliminar archivos u ocultar de otro modo su actividad en el dispositivo.

Los investigadores deben correlacionar los registros de ISE con la telemetría almacenada en otros sistemas, incluidos los eventos del firewall y los datos de flujo de red. Deben buscar cargas salientes no explicadas desde un nodo de ISE, descargas que impliquen direcciones externas sospechosas y conexiones entrantes o salientes inusuales asociadas con la implementación.

Si se sospecha que ha habido un compromiso, Cisco recomienda encarecidamente volver a crear las imágenes de los nodos afectados y restaurarlos desde copias de seguridad de la configuración cuando sea necesario. Aplicar simplemente el parche no elimina la persistencia ni los cambios no autorizados que un atacante pueda haber introducido previamente.

Aplicar primero el parche y determinar después si ya se produjo un acceso

La respuesta inmediata tiene dos líneas de actuación paralelas: cerrar la vía vulnerable de la API y determinar si los atacantes la alcanzaron antes de aplicar la corrección.

Los administradores deben identificar todos los nodos de ISE e ISE-PIC, verificar su versión exacta, instalar el parche correspondiente y restringir el tráfico de administración mediante iACL hasta completar la implementación. Los sistemas con la versión 3.0 requieren una migración, no un parche convencional.

Después deben conservar y revisar los registros disponibles, recopilar pruebas de red externas y tratar la actividad inexplicada en el plano de administración como un posible incidente. Cuando los indicadores apunten a una explotación exitosa, volver a crear la imagen del sistema es más seguro que confiar en la integridad de un sistema que podría haber sido controlado con privilegios root.