Cisco ISE CVE-2026-76460: CVSS 10 con Explotación Activa y Deadline CISA

Por qué este CVE te tiene que importar aunque no corras ISE

Cisco publicó el 16 de septiembre de 2026 el advisory cisco-sa-ISE-ABP-VNSW7Tn5 para CVE-2026-76460, una vulnerabilidad de tipo authentication bypass en una API de Cisco Identity Services Engine (ISE) e ISE Passive Identity Connector (ISE-PIC). El CVSS es 10.0 — el máximo posible — y CISA la agregó al catálogo KEV el mismo día del disclosure, con fecha de remediación al 19 de septiembre de 2026. Cisco confirmó que hay explotación activa.

El vector CVSS 3.1 es AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: attack vector por red, baja complejidad, sin privilegios requeridos, sin interacción del usuario, con cambio de scope (Scope: Changed). Eso significa que una sola petición HTTP bien armada a la API equivocado te da acceso root al appliance de NAC.

Lo que vuelve a este CVE distinto del típico CVSS 10 es que la descubridora no fue una investigación proactiva de Cisco: fue un caso de soporte TAC. Un cliente llegó con un ticket y, mientras lo trabajaban, Cisco encontró que la API que usa ISE para su propia gestión tenía controles de autenticación insuficientes. Eso implica que el agujero estuvo accesible públicamente hasta que alguien lo reportó.

Qué versiones de ISE están afectadas y dónde hay parche

El NVD lista 30 versiones afectadas entre ISE Software y ISE-PIC. Las ramas principales con parches disponibles son:

Rama de ISE	Versiones afectadas	Parche disponible
ISE 3.0	todas las publicadas	Sin parche — fin de soporte de software. Hay que migrar.
ISE 3.1	3.1.0 Patch 8, Patch 9 (y ramas previas)	3.1 Patch 12
ISE 3.2	3.2 Patch 10 y anteriores	3.2 Patch 11
ISE 3.3	3.3 Patch 1, 2, 3 y siguientes hasta Patch 11	3.3 Patch 12
ISE 3.4	3.4 base, Patch 1 a Patch 6	3.4 Patch 7
ISE 3.5	3.5 base, Patch 1, Patch 2, Patch 3	3.5 Patch 4
ISE-PIC 3.4	3.4 base + Patch 1 a 6	incluida en 3.4 Patch 7
ISE-PIC 3.5	3.5 base + Patch 1, 2, 3	incluida en 3.5 Patch 4

Si tu ISE corre en una rama donde el advisory no lista un parche, significa que esa rama está fuera de mantenimiento y la única ruta soportada es migrar. En particular ISE 3.0 alcanzó fin de soporte de software, así que cualquier appliance en 3.0 no recibe fix para este CVE ni para los próximos.

Cómo se explota — y por qué no necesitas credenciales

La vulnerabilidad vive en una API interna que ISE expone para su propia interfaz web de administración. El fallo es un control de autenticación insuficiente sobre un endpoint específico. Un atacante remoto, sin credenciales y sin necesidad de engañar a ningún usuario, envía una request armada contra ese endpoint y se salta la autenticación del portal web de gestión.

Una vez adentro del portal con un bypass, dependiendo de los permisos que el endpoint otorgue, el atacante escala a ejecución de comandos con privilegios de root dentro del appliance. Eso es lo que vuelve al CVE particularmente incómodo: no estás parcheando una funcionalidad opcional, estás parcheando la superficie de gestión misma del NAC. Y la superficie de gestión es, justamente, la que controla quién se autentica contra tu red.

El detalle que más preocupa a los equipos de seguridad es que Cisco advierte que el root access permite al atacante borrar huellas y modificar logs, lo que dificulta saber si un nodo fue comprometido. La forense queda complicada porque las pistas internas pueden haber sido limpiadas desde adentro.

Cómo saber si ya estás comprometido

Cisco recomienda revisar logs de ISE buscando nombres de usuario sospechosos en cada nodo de un despliegue distribuido, y revisar logs de red y firewall mantenidos fuera del dispositivo afectado por señales de uploads o downloads inesperados — porque los logs internos pueden haber sido alterados.

Una forma práctica de empezar es correr este filtro sobre los operations logs de ISE desde el nodo de administración, exportando a un archivo en una máquina externa antes de aplicar el parche:

# Exportar logs de operaciones a un host externo antes de parchar
# (asume que tienes acceso SSH a un jump host)
ssh admin@ise-pam 'show logging export /tmp/ise_ops_pre_patch.tar' 
  | scp admin@ise-pam:/tmp/ise_ops_pre_patch.tar ./evidencia/
# Filtrar eventos de autenticación sospechosos
gunzip -c evidencia/ise_ops_pre_patch.tar 
  | grep -E "Authentication|Admin Login|API Access|Endpoint Auth" 
  | awk '$5 ~ /[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/ {print}' 
  | sort -u > evidencia/auth_events_pre_patch.txt
# Buscar usernames que NO están en tu directorio activo conocido
comm -23 
  <(awk '{print $NF}' evidencia/auth_events_pre_patch.txt | sort -u) 
  <(cat ldap_known_users.txt | sort -u)

Si encuentras usuarios que no existen en tu LDAP o Active Directory, o eventos Admin Login desde IPs que no son de tu red de administración, tratá el nodo como comprometido y seguí el procedimiento de respuesta.

Un patrón complementario es comparar la cantidad de eventos de autenticación exitosa contra la API con tu baseline. Si normalmente ves 20-50 eventos/día de admins legítimos y de golpe hay 800 en una hora, algo se rompió — incluso si los usernames parecen válidos.

# Detectar picos anómalos en la API de gestión de ISE
# Asume que el log ya está en formato CSV con timestamp,source,event,user
awk -F, '$3 == "API_SUCCESS" {print $1}' 
  evidencia/auth_events_pre_patch.txt 
  | cut -d' ' -f1,2 | sort | uniq -c 
  | awk '$1 > 100 {print "ANOMALO:", $0}'
# Buscar accesos a endpoints sensibles que NO estaban en uso legítimo
grep -E '/admin/api/v1/system/|/api/v1/deployment|internal/credentials' 
  evidencia/auth_events_pre_patch.txt 
  | awk -F, '{print $1, $2, $4}' | sort -u

Estos endpoints de la API interna no se llaman en operación normal — solo cuando un admin está activamente reimagenando, restaurando configuración o rotando credenciales. Si aparecen accesos sin un ticket de cambio abierto, casi con certeza es el atacante.

Mitigación temporal si todavía no puedes parchear

Cisco explícitamente dice que no hay workaround para la vulnerabilidad. Lo que recomienda como mitigación temporal es restringir el tráfico al ISE mediante access control lists en la infraestructura de red (firewall, switch L3, security group en cloud) de modo que solo el jump host de administración y los nodos internos del cluster ISE puedan llegar al puerto de gestión.

En la práctica esto se parece a:

# Ejemplo conceptual con nftables en un router Linux de frontera
# Solo el jump host (10.20.30.5) y la red de nodos ISE (10.40.0.0/24)
# pueden llegar al puerto 443 de los appliances ISE.
nft add rule ip filter INPUT ip saddr != { 10.20.30.5, 10.40.0.0/24 } 
  tcp dport { 443, 8443, 9060 } drop comment 'mitigacion CVE-2026-76460'
# Verificar que la regla está cargada
nft list chain ip filter INPUT | grep -A1 'mitigacion CVE'

Importante: esta mitigación no te salva. Si el atacante ya está dentro de tu red interna — algo común porque CVE-2026-76460 está siendo explotado activamente — la ACL no lo detiene. Es solo para ganar tiempo hasta el cambio de mantenimiento.

Adicionalmente, si tu ISE está expuesto directamente a internet (algo que no debería pasar en ningún diseño razonable, pero pasa), tratá esa exposición como un incidente abierto hasta confirmar lo contrario.

Procedimiento de remediación en orden

El orden importa. Parchear un ISE que ya fue comprometido te deja con el rootkit adentro y el patch aplicado. Cisco recomienda enfáticamente reimagenar los nodos con evidencia de explotación y restaurar desde backup verificado.

# Paso 1 — Snapshot de configuración Y logs externos ANTES de tocar nada
# (esto asume que tienes backups centralizados; si no, parar acá y empezar)
ssh admin@ise-pam 'show running-config' > evidencia/ise_running_$(date +%F).txt
ssh admin@ise-pam 'show backup history' > evidencia/ise_backup_history.txt
# Paso 2 — Aislar el nodo sospechoso de la red de producción
# (mantener solo acceso desde jump host de admin)
ssh admin@core-sw 'configure terminal
  interface Vlan40
   no ip access-group ISE-PROD-IN
   ip access-group ISE-QUARANTINE-IN
   end
  write memory'
# Paso 3 — Reimaginar y restaurar desde backup pre-incidente conocido
# (Cisco recomienda usar la imagen oficial y NO solo actualizar in-place)
# Paso 4 — Aplicar el patch de la rama correcta
# ISE 3.3 → 3.3 Patch 12
# ISE 3.4 → 3.4 Patch 7
# ISE 3.5 → 3.5 Patch 4
# (verificar versión post-patch con application upgrade status)
# Paso 5 — Rotación de TODAS las credenciales de administración
# Cisco PSIRT lo recomienda porque el atacante pudo extraer secretos.

Si tienes un cluster distribuido, hazlo nodo por nodo y mantené el cluster en quorum — un nodo reimagenado sin los demás se vuelve a sincronizar, pero un nodo parcheado con código antiguo sigue vulnerable.

# Validar post-patch que la versión correcta está corriendo
# y que el endpoint vulnerable responde con autenticación funcionando
ssh admin@ise-pam 'show version' | grep -E "Patch|Version"
# Esperado para 3.4: "3.4.0.608" o el número que tu release notes diga
# Si dice "3.4.0.608" pero el advisory de tu parche es más nuevo, NO parcheaste.
# Probar el endpoint vulnerable con autenticación FALLIDA (debe rechazar)
curl -k -s -o /dev/null -w "%{http_code}n" 
  https://ise-pam.example.local/admin/api/v1/system/health 
  -H "Accept: application/json"
# Esperado: 401 Unauthorized o 403 Forbidden (NO 200)
# Y con autenticación válida (debe permitir a un admin legítimo)
curl -k -u admin:"$ISE_ADMIN_PASS" -s -o /dev/null -w "%{http_code}n" 
  https://ise-pam.example.local/admin/api/v1/system/health
# Esperado: 200 OK

Si el endpoint devuelve 200 sin credenciales, todavía tienes la versión vulnerable corriendo y la operación de patch falló. No sigas con el resto de los nodos hasta resolver.

Por qué CISA puso deadline de 3 días y qué significa BOD 26-04

El deadline del 19 de septiembre (3 días desde el 16) es la ventana que usa CISA bajo BOD 22-01 para vulnerabilidades de máxima criticidad con exploitation activa. Pero lo que cita el aviso específicamente es BOD 26-04 Prioritizing Security Updates Based on Risk, que es la actualización 2026 del marco de priorización de parches.

Lo que cambió con BOD 26-04 es que ya no se parchea por puntaje CVSS en abstracto, sino por exposición real. Un ISE aislado detrás de jump host y sin tráfico desde internet tiene un perfil de riesgo distinto al de un ISE con el puerto 443 abierto. Si tu ISE está segmentado, puedes negociar una ventana un poco más amplia con tu equipo de compliance; si está expuesto, parchar es hoy.

El BOD 26-04 también exige evaluar la exposición a internet de cada activo antes de aplicar la guía de remediación. Lo que en la práctica significa: si no puedes demostrar que tu ISE no fue tocado, lo tratás como tocado.

Para el sysadmin con homelab: ¿vale la pena este CVE?

La respuesta corta: probablemente no tienes ISE en un homelab porque es software enterprise que necesita un appliance dedicado o VM con hardware serio (mínimo 16 GB RAM para un nodo pequeño) y una licencia por sesión. Pero el patrón importa más que el producto.

Lo que CVE-2026-76460 ilustra es un fallo de categoría: API de gestión con control de autenticación insuficiente. Esto se repite en appliances de seguridad, NAS, routers, switches gestionados, firewalls UTM. Cada vez que comprás un appliance “para dejarlo y olvidarlo”, estás confiando en que la superficie de gestión está bien hecha. Y este CVE muestra que ni siquiera Cisco, con un PSIRT de primera línea, se salva de que un caso de soporte descubra el agujero.

Para el sysadmin que opera infra con appliances Cisco, la lección operativa es triple:

• Segmentar la gestión por diseño. El puerto 443 del ISE no debería estar en la misma VLAN que los servidores. Si lo está, moverlo es la prioridad antes incluso de parchar.
• Asumir que los logs internos pueden ser borrados. Exportar logs críticos a un SIEM o al menos a un host externo es lo único que te salva la forense.
• No correr ISE 3.0 ni nada fuera de soporte. “Funciona y no quiero migrar” deja al appliance fuera del radar de parches críticos. Si Cisco no lo parchea, no puedes protegerte.

Y un consejo menos obvio: si tienes ISE-PIC expuesto (que es más común en redes con autenticación 802.1X distribuida), este CVE lo golpea igual. El módulo Passive Identity Connector no es una versión “lite” exenta de la API vulnerable.

Para quien opera appliances Cisco en general — switches Catalyst, routers ISR, firewalls ASA/FTD — vale la pena revisar qué API de gestión está expuesta. Una forma rápida es chequear desde tu jump host con un escaneo limitado a tu segmento de gestión:

# Enumerate API endpoints conocidos en appliances Cisco en tu segmento
# (solo en red de gestión, NO en producción)
nmap -p 443,9060,8443 --script http-title 
  --script-args 'http.useragent=CiscoHealthCheck' 
  10.40.0.0/24
# Para cada appliance, listar endpoints /api/v1/ documentados
for host in $(nmap -p 443 -sL 10.40.0.0/24 | awk '/Nmap scan/{print $NF}'); do
  echo "== $host =="
  curl -sk -o /dev/null -w "%{http_code} %{url_effective}n" 
    "https://${host}/api/v1/system/version"
done
# Validar que el endpoint responde 401 sin auth (NO 200)
# Cualquier host que devuelva 200 es candidato a CVE-2026-76460 u homólogos

Conclusión

CVE-2026-76460 es un CVSS 10 con exploitation activa confirmada, parche disponible en todas las ramas soportadas excepto 3.0, y deadline regulatorio de 3 días. No hay workaround real — solo mitigación temporal con ACLs. Si operas ISE, segmentar la gestión, exportar logs externos y aplicar el patch de tu rama hoy son las tres acciones no negociables. Si no operas ISE pero usas otros appliances Cisco, este CVE es un buen momento para revisar qué superficies de gestión están accesibles y qué tan parcheadas están.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux