Cisco ISE, un 10 sin mitigación: tu red ya decidió qué hace sin él

Abre el show run de un switch de planta y busca dos cosas: cuántos servidores RADIUS hay configurados de verdad, y qué deadtime tienen. Eso es lo que va a hacer tu red el día que el motor de políticas no conteste. El valor por defecto de radius-server deadtime en IOS y en IOS XE es 0.

Cisco lo documenta con la consecuencia pegada al lado. Si no se especifica el deadtime vale 0, «which brings the server back to the UP state right away», y por eso «the RADIUS server state could flap, causing additional authentication issues». En la práctica: el switch tarda en marcar muerto un servidor, porque hacen falta los dos criterios —un tiempo mínimo sin respuesta válida y un número de timeouts consecutivos—, y en cuanto lo marca, lo revive. A la siguiente autenticación vuelve a preguntarle al mismo servidor que está reiniciándose. El otro servidor, el que está levantado, recibe la petición solo después de que el primero agote sus reintentos, si es que llega. Dos servidores configurados y deadtime 0 hacen un servidor con cola de espera.

Ese detalle lleva años ahí y casi nunca molesta. Esta semana sí, porque a mucha gente le toca reiniciar sus nodos de ISE con prisa.

El aviso

Cisco publicó el 16 de septiembre cisco-sa-ISE-ABP-VNSW7Tn5, versión 1.0 y ya marcada como final. CVE-2026-76460, CVSS 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, CWE-648. La causa, literal: «insufficient authentication control on an API endpoint». Afecta a Identity Services Engine y al Passive Identity Connector en las ramas 3.1, 3.2, 3.3, 3.4 y 3.5, y se corrige en 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 y 3.5 Patch 4. Si corres la 3.0, la tabla del aviso no te ofrece parche: dice que esa rama ha llegado a fin de mantenimiento de software y que hay que migrar a una versión soportada que incluya la corrección. No hay workarounds. Y el PSIRT declara que tiene constancia de explotación activa.

CISA lo metió en el catálogo de vulnerabilidades explotadas ese mismo 16, en la versión 2026.09.16, bajo la directiva BOD 26-04 y con la marca de triaje forense. Entraron tres CVE ese día, los tres con fecha límite el 19 de septiembre: este, el fallo de permisos del plugin de copias de Acronis del que escribíamos esta misma mañana y un fallo del módem celular de los Google Pixel. El 19 cae en sábado, así que el último día laborable es mañana.

Antes del parche va el access.log

La parte del aviso que casi no se ha citado en las coberturas de ayer es la sección de indicadores de compromiso, y es la que cambia el orden de las tareas. Cisco dice que para confirmar un intento de explotación hay que revisar el access.log y buscar nombres de usuario sospechosos, y da el sitio donde mirar. Debajo viene el párrafo que conviene leer dos veces: tras una explotación exitosa, los atacantes pueden obtener «command execution with root privileges», y precisamente por ese nivel de acceso «evidence of exploitation and indicators of compromise may be removed or hidden by the threat actors». De ahí la recomendación de cruzar los registros de red y de cortafuegos externos al aparato afectado.

Lo que no sabemos es cómo se está explotando. Cisco no publica detalle técnico del ataque ni la fecha desde la que se observa, y quien te cuente hoy el exploit paso a paso se lo está inventando. Con lo publicado basta para ordenar el trabajo: mirar el log antes de tocar nada, parchear, y decidir qué haces si el log tiene algo.

Por qué un 10 y no un 9,8

Casi todos los saltos de autenticación remotos se quedan en 9,8. Este llega al 10 por una letra: S:C, scope changed, que en CVSS significa que el componente vulnerable y el que sufre el impacto no son el mismo. El propio aviso dice cuál es ese cruce unos párrafos más abajo: lo que se salta es la autenticación de la interfaz de gestión web, y lo que se obtiene es ejecución de comandos como root. La caja entera, no la aplicación.

La puntuación se queda ahí, porque CVSS no puntúa el daño aguas abajo. El daño aguas abajo es el que te va a ocupar la tarde, y para eso conviene separar dos cosas que se confunden. El gestor de cortafuegos del que hablábamos hace unos días es un plano de gestión: se consulta cuando alguien va a cambiar algo. ISE tiene uno igual, y además es otra cosa: un plano de decisión en tiempo real, en el camino crítico de cada autenticación 802.1X, cada MAB de una impresora y cada autorización de VPN. Se le pregunta miles de veces al día, cuando alguien enchufa un cable. Un plano de decisión se puede robar, y también se puede apagar. Lo segundo es lo que casi nunca está decidido.

El parche rueda, si tienes a dónde caer

Lo que frena el parcheo de un control de acceso a la red es un miedo razonable: dejar la oficina sin autenticar durante la ventana. Para un despliegue distribuido, el fabricante tiene respuesta. Cisco lo escribe así: «Cisco ISE installs the patch on the primary node first, then proceeds to the secondary nodes». Si falla en el primario no continúa hacia los secundarios; si falla en un secundario, sigue con el siguiente; y cada nodo se reinicia cuando acaba su propia instalación. El requisito previo que anota el manual es dejar desmarcada la casilla de auto-failover del PAN mientras dura la operación. Lo que la documentación no promete en ningún sitio es que dos secundarios no se solapen: eso lo compruebas tú, con un nodo de prueba o mirando el reloj.

Ahora la parte que no sale en ninguna guía, porque describe a buena parte de nuestros clientes: en una oficina de treinta personas, ISE no es un despliegue distribuido. Es una máquina, o dos. Ahí no rueda nada. Cuando el único nodo que atiende autenticaciones se reinicia, no hay segundo al que caer, y todo lo que viene después de este párrafo deja de ser un matiz de configuración para convertirse en la pregunta entera.

Los dos modos que decides, y el tercero que ya tienes

Cuando el servidor no responde, un puerto con 802.1X activado se comporta de una de estas tres maneras. Dos son decisiones. La tercera suele ser un resto.

• Cerrado. Sin servidor no hay autorización. La documentación de los Catalyst lo describe sin adornos: sin el bypass, «the client attempts and fails authentication indefinitely, and the switch port remains in the spanning-tree blocking state». Es lo que ocurre por defecto en cuanto activas 802.1X, porque la tabla de configuración por defecto trae «Inaccessible authentication bypass: Disabled». Seguro y caro: el portátil que arranca no entra, y la impresora que se reinició tampoco.
• El segundo es el inaccessible authentication bypass, también llamado autenticación crítica o política de fallo de AAA: si el servidor no responde, el switch pone el puerto en estado de autenticación crítica. Para un equipo que aún no estaba autorizado, en la VLAN que hayas configurado; pero para uno que ya lo estaba y le toca reautenticar, la guía avisa de que se queda «in the current VLAN, which might be the one previously assigned by the RADIUS server». O sea, en la que le dio ISE, no necesariamente en la que tú elegiste. Al volver el servidor puedes hacer que los puertos críticos reinicialicen sus hosts y los reautentiquen.
• Y luego está el puerto que lleva authentication open, donde el tráfico pasa aunque la autenticación no haya terminado o no haya respuesta de nadie. Es una función documentada y legítima: así se despliega 802.1X sin romper la oficina el primer día, y así se monitoriza antes de aplicar de verdad. También es el estado en el que se queda una cantidad incómoda de despliegues, porque alguien lo puso para que dejaran de llegar tickets, funcionó, y nadie lo quitó. Si es tu caso, el CVSS 10 de esta semana no cambia gran cosa en tus switches: tu control de acceso ya estaba en modo degradado permanente.

Ninguno de los tres es el correcto en abstracto. Un hospital y un laboratorio no quieren lo mismo, y una nave con lectores de producción tampoco quiere lo mismo que una oficina de treinta personas. Lo que no es defendible es no saber en cuál estás.

Por eso somos prudentes con el diagnóstico fácil. El motivo que se dice en voz alta para retrasar el parche de un NAC es la ventana de mantenimiento, y la ventana de mantenimiento suele ser la parte barata, porque la eliges tú. La cara es la otra: la que elige un tercero. Alguien que pueda tumbar la disponibilidad de tu motor de políticas no necesita saltarse tu control de acceso a las nueve y media de un martes; le basta con obligarte a decidir en caliente, con la centralita sonando, entre dejar a la plantilla fuera o abrir la puerta. Es la redundancia que existe en el diagrama y no sobrevive al procedimiento, otra vez.

El orden que seguiríamos

Primero el log, y esto es lo que cambia respecto a un parche normal. Antes de reiniciar nada, revisa el access.log de cada nodo del despliegue buscando usuarios que no reconozcas, tal como indica el aviso. Si aparece algo, el parche deja de ser el final del trabajo y pasa a ser el principio: la recomendación del fabricante es reinstalar ese nodo y restaurar la configuración. Y como la ejecución es con privilegios de root, los indicadores pueden haber sido borrados desde dentro; los registros que valen de verdad son los que están fuera del aparato, en tu cortafuegos y en tu colector.

Después el parche, con el número del parche y no el de la rama. «Estamos en 3.3» no es una respuesta: las referencias son 3.1 P12, 3.2 P11, 3.3 P12, 3.4 P7 y 3.5 P4, y en la 3.0 no hay parche, hay migración. Mira también el Passive Identity Connector, que está en la lista de afectados y se olvida porque nadie lo llama «el ISE». Y ya que estás, la pregunta que plantea el AV:N: desde qué red se llega a esa interfaz de administración. No tiene motivo para ser alcanzable desde las VLAN de usuario, ni desde la de invitados, ni desde internet.

Y luego, ya con calma, la parte que sobrevive a este CVE. Cuenta en el show run —no en el diagrama— cuántos servidores ve cada switch, y pon un deadtime que no sea cero, coherente con lo que tarda un nodo tuyo en reiniciarse. Decide si quieres sondeo con automate-tester entendiendo el intercambio: sin probe-on sondea siempre, detecta la caída antes de que la pague un usuario y a cambio manda tráfico constante contra el servidor; con probe-on sondea solo cuando ya está marcado muerto, así que no te ahorra al primer usuario pero recupera el servidor sin esperar a que expire el deadtime. Cualquiera de las dos vale más que el valor de fábrica, que es no tener ninguna.

Queda el inventario que decide todo lo anterior y que casi nadie consulta antes de elegir: los dispositivos que entran por MAB y no tienen a nadie detrás. Impresoras, cámaras, lectores, control de accesos, la máquina de la nave, los teléfonos. Cuando se quedan fuera no abren ticket: se quedan mudos, y por eso el coste del modo cerrado no aparece en ninguna estadística de soporte. Y con esa lista delante, el último paso: apagar un nodo a propósito un martes a las diez y mirar qué pasa en un puerto real, con un portátil real. Es el paso que más resistencia genera y el único que produce certeza; lo hacemos con todo lo que consideramos crítico, por el mismo motivo por el que cronometramos las restauraciones. Un plan que nadie ha ensayado es una intención con formato de documento.

Queda una idea que es opinión nuestra: un NAC no es Zero Trust. Un 802.1X que autentica el puerto y después suelta al equipo en una VLAN plana sigue siendo un perímetro, solo que movido al armario de planta. El síntoma lo delata: si la autorización siguiera valiendo algo después de cruzar la puerta, el modo degradado de la puerta importaría bastante menos de lo que importa. Es el mismo argumento que hacíamos sobre tratar al proveedor de identidad como una aplicación más: la pieza que decide no puede vivir en el mismo saco que las piezas sobre las que decide. Y que conste que ISE hace bien un trabajo que intentan muchos y consiguen pocos; un control de autenticación insuficiente en un endpoint de API aparece en productos de todos los tamaños, y este mes lleva ya unos cuantos.

Nota de fuentes

Consultado todo el 17 de septiembre de 2026. Uno: el aviso cisco-sa-ISE-ABP-VNSW7Tn5 de Cisco, publicado el 16-09-2026 en versión 1.0 final, de donde salen el CVE, el CVSS 10.0 y su vector, la CWE-648, la frase sobre el control de autenticación insuficiente en un endpoint de API, las ramas afectadas 3.1 a 3.5 con ISE-PIC, los parches corregidos, la nota de que la 3.0 ha llegado a fin de mantenimiento de software y hay que migrar, la ausencia de workarounds, la explotación activa constatada por el PSIRT, y toda la sección de indicadores de compromiso: revisar el access.log buscando nombres de usuario sospechosos, las citas sobre la ejecución de comandos como root y sobre que los indicadores pueden ser borrados u ocultados por los atacantes, la recomendación de cruzar los registros de red y cortafuegos externos al aparato, y la de reinstalar el nodo y restaurar la configuración si se sospecha actividad maliciosa. Dos: el catálogo de vulnerabilidades explotadas conocidas de CISA, versión 2026.09.16, leído en su JSON: las tres entradas añadidas el 16-09-2026 (CVE-2026-76460 de Cisco ISE, CVE-2026-87886 de Acronis Backup y CVE-2026-58704 de Google Pixel), las tres con fecha límite 19-09-2026 y marca de triaje forense, bajo la directiva BOD 26-04. Que el 19 caiga en sábado es aritmética de calendario. Tres: las guías de actualización de Cisco ISE (ramas 3.1 y 3.3), de donde sale la frase literal sobre el orden primario-secundarios, el comportamiento ante fallo en el primario o en un secundario, el reinicio de cada nodo al terminar su instalación y el requisito de dejar sin marcar la casilla de auto-failover del PAN. Que la documentación no promete la no-solapación de reinicios entre secundarios es una lectura nuestra de lo que esas guías no dicen, y va dicha como tal. Cuatro: el artículo de soporte de Cisco «Understand AAA Dead Detection and Deadtime on IOS XE» y la referencia de comandos de radius-server deadtime, de donde salen el valor por defecto 0, las dos citas literales sobre el retorno inmediato al estado UP y el flapeo, los dos criterios de marcado como muerto, y el comportamiento de automate-tester con y sin probe-on. Cinco: las guías de configuración de seguridad de los Catalyst (9300 y 1000): la descripción del inaccessible authentication bypass como autenticación crítica o política de fallo de AAA, el comportamiento en la VLAN crítica para un puerto no autorizado y la advertencia de que en la reautenticación de un puerto ya autorizado se usa la VLAN actual, la reinicialización de hosts al volver el servidor, la frase sobre lo que ocurre sin la función —el cliente falla indefinidamente y el puerto queda en bloqueo de spanning tree—, la tabla de configuración por defecto de 802.1X con «Inaccessible authentication bypass: Disabled» y la reautenticación periódica deshabilitada, y la sección sobre puertos ya autenticados, que permanecen autenticados sin requerir comunicación con el servidor RADIUS. La existencia de authentication open como modo de despliegue es función documentada de Cisco; que una parte incómoda de los despliegues se quede ahí es observación nuestra, no un dato medido. También es opinión nuestra, y va dicha como tal, que un NAC no es Zero Trust y que la ventana de mantenimiento es la parte barata del problema. No sabemos cómo se está explotando este fallo y no lo afirmamos.