El 16 de septiembre Cisco publicó un grupo de avisos sobre Cisco Identity Services Engine (ISE), el producto con el que muchas organizaciones deciden qué equipo puede conectarse a su red. Dos cosas salieron el mismo día, y conviene separarlas porque son muy distintas.
La primera es CVE-2026-76460, un bypass de autenticación con 10.0 que Cisco reconoce como explotado en ataques reales, y que CISA sumó al catálogo ese mismo día con plazo al 19 de septiembre, ya vencido. No hay workaround.
La segunda es una hardening release: el resultado de una revisión interna de seguridad de ISE. Y ahí está lo que hace distinta a esta nota, porque Cisco explica en el aviso cómo decidió numerar lo que encontró:
"To assist customers in patching and streamline the disclosure process, Cisco has grouped these issues by their underlying vulnerability class — Common Weakness Enumeration (CWE) — and assigned a single Common Vulnerabilities and Exposures identifier (CVE ID) to each CWE grouping."
Un CVE por clase de vulnerabilidad, no por vulnerabilidad.
Qué significa que un CVE represente una clase y no una falla
La convención con la que trabaja todo el mundo —escáneres, inventarios, informes de proveedores, planillas de cumplimiento— es que un identificador CVE señala una vulnerabilidad concreta: un lugar del código, un mecanismo, un puntaje que describe ese mecanismo.
Acá no. Cada uno de los seis identificadores cubre un pilar de CWE, que es el nivel más alto y más abstracto de esa clasificación. Y el aviso es explícito sobre qué representa el número que lo acompaña:
"The CVSS score that is assigned to each CVE ID represents the maximum potential severity of the single most impactful underlying vulnerability within that specific CWE category."
El puntaje es el de la peor falla del grupo, no el de una falla.
No es una lectura forzada del aviso: la propia ficha de cada CVE en NVD lo dice en plural. La de CVE-2026-20130 empieza con "The vulnerabilities tracked by CVE-2026-20130 are related to improper neutralization of special elements issues that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-74." Las vulnerabilidades, con ese identificador, en plural.
Los seis grupos de CVE-2026-20130 a CVE-2026-20287
Estos son los seis, con el puntaje que Cisco asignó a cada clase. Los seis siguen en estado Awaiting Analysis en NVD, así que por ahora el único puntaje disponible es el del fabricante.
Lo que cubre cada uno, según el propio aviso:
| CVE | Clase | Qué abarca |
|---|---|---|
| CVE-2026-20130 | CWE-74 | Inyección de comandos, XSS, inyección de XML, de código y de recursos |
| CVE-2026-20192 | CWE-284 | Autorización, autenticación, privilegios y bypasses |
| CVE-2026-20234 | CWE-522 | Contraseñas guardadas de forma recuperable y codificación débil |
| CVE-2026-20194 | CWE-669 | Exposición de datos en tránsito y subida de archivos sin restricción |
| CVE-2026-20237 | CWE-20 | Validación indebida de entradas |
| CVE-2026-20287 | CWE-269 | Gestión indebida de privilegios |
Mirá la segunda fila. CVE-2026-20192 tiene 10.0 y abarca "autorización, autenticación, privilegios y bypasses", que es prácticamente todo lo que puede salir mal en el control de acceso de un producto cuya función es el control de acceso. Ese identificador no describe un problema: nombra un territorio.
Por qué Cisco lo hizo así, y qué se gana con eso
Vale decirlo sin sarcasmo, porque el motivo que da es razonable y la mitad del argumento es correcta.
Cisco encontró estas fallas en una revisión interna propia, no porque alguien las reportara desde afuera. Las corrige todas en la misma actualización, así que para el administrador que tiene que parchear, la lista de acciones es idéntica tenga seis identificadores o sesenta: instalar el parche de su rama. Publicar sesenta CVE con sesenta descripciones no le cambiaría nada a esa persona, y sí le daría a cualquier atacante un mapa mucho más detallado de dónde mirar en las versiones viejas.
El costo no está del lado de parchear. Está del lado de medir. Y ahí aparecen tres consecuencias concretas:
- Contar CVE deja de significar algo. Un informe que diga "ISE tuvo 7 vulnerabilidades este mes" es literalmente cierto en identificadores y falso en fallas, por un factor que nadie publicó.
- El puntaje no describe lo que uno cree. Un 10.0 que es el techo de una categoría no dice que exista una falla de 10.0 explotable en tu instalación; dice que la peor del grupo llega a eso. Y a la inversa: un 6.5 de grupo puede contener algo que en tu configuración particular importa más.
- Desaparece el detalle que permite priorizar. Sin mecanismo, sin vector por falla y sin versiones por falla, no hay forma de decidir cuál de las cosas agrupadas te toca. La única salida es tratar el grupo entero como la peor de sus partes.
El contraste con la misma semana es útil: GitLab publicó el 10 de septiembre una entrega con 17 CVE, uno por falla, cada uno con su puntaje, su rango de versiones y el nombre de quien la reportó. Ahí se podía ver que cuatro de las diecisiete terminaban en exposición de credenciales, que es exactamente el tipo de lectura que la agrupación por clase impide.
Qué hay que hacer con CVE-2026-76460, la que sí se está explotando
Separada de las seis, y más urgente que todas ellas, está la que motivó la entrada al catálogo de CISA.
CVE-2026-76460 es un bypass de autenticación por control insuficiente en un endpoint de API: un atacante sin credenciales manda una petición preparada y accede al equipo salteando la interfaz de administración. Puntaje 10.0 con vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, tipo CWE-648, identificador interno de Cisco CSCww39530.
- Afecta a Cisco ISE y a ISE-PIC, el conector de identidad pasiva, "regardless of device configuration".
- No hay workaround. La única acción es actualizar.
- Corrige en 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 y 3.5 Patch 4. La rama 3.0 llegó al fin de mantenimiento de software y no tiene corrección: ahí el camino es migrar.
- El indicador que publica Cisco es revisar
access.logbuscando nombres de usuario sospechosos, y hacerlo en cada nodo si el despliegue es distribuido.
Los dos avisos críticos de Cisco de septiembre salieron de casos de soporte
Hay un detalle en la sección de créditos que ya apareció hace seis días y que conviene mirar junto.
El aviso de ISE dice que la falla "was found during the resolution of a Cisco Technical Assistance Center (TAC) support case". El de Cisco Secure Email Gateway, publicado el 14 de septiembre con otro 9.8 explotado y también sin workaround, dice exactamente lo mismo: se encontró resolviendo un caso de soporte.
Dos productos distintos, identificadores consecutivos —76460 y 76461—, los dos críticos, los dos con explotación confirmada, los dos sin mitigación, y los dos descubiertos atendiendo el problema de un cliente.
Eso dice algo que vale más que cualquiera de los dos casos: cuando el origen de un aviso es un caso de soporte, el aviso es posterior al daño por definición. Alguien ya fue atacado, llamó, y la investigación encontró la causa. Es el mismo patrón que MikroTik, donde los ataques llevaban un día cuando salió el aviso, y que las tres fallas del kernel, donde pasaron 378 días entre la corrección y la confirmación de que se usaba.
¿A quién afecta el aviso de Cisco ISE?
A organizaciones con Cisco ISE o ISE-PIC desplegado, que no es el perfil de una PyME chica: es el de universidades, hospitales, organismos públicos, bancos medianos, proveedores de internet y empresas de varios cientos de empleados que controlan quién se enchufa a su red.
Si tu empresa no tiene ISE, la parte operativa de esta nota no te toca. La parte que sí te toca, tengas o no un Cisco, es la de leer informes: cuando alguien te pase un listado de vulnerabilidades, la pregunta ya no es cuántos CVE hay, sino qué representa cada uno.
¿Quién puede ignorar el aviso de Cisco ISE?
Quien no administre ISE ni ISE-PIC. Es un producto de control de acceso a red empresarial, no algo que venga con un router ni con un servicio en la nube.
Ahora, si tu red la administra un tercero, la pregunta legítima es si usa ISE y en qué parche está, porque un bypass de autenticación de 10.0 en el equipo que decide quién entra a la red no se queda contenido en ese equipo.
¿Qué le pregunto a quien administra mi red sobre Cisco ISE?
- ¿Usan Cisco ISE o ISE-PIC? Si la respuesta es no, termina ahí.
- ¿En qué parche están? Tiene que ser 3.1 P12, 3.2 P11, 3.3 P12, 3.4 P7 o 3.5 P4, como mínimo. Si están en la rama 3.0, no hay parche: hay que migrar.
- ¿Revisaron
access.logen todos los nodos buscando nombres de usuario que no correspondan? Es el indicador que publicó Cisco, y en despliegues distribuidos hay que mirar equipo por equipo. - ¿Aplicaron también la hardening release? Son correcciones distintas de la falla explotada, y van en la misma actualización.
Y una que sirve más allá de Cisco, para cualquier informe de vulnerabilidades que recibas: pedí que cada hallazgo diga qué es, no sólo cuánto puntúa. Un listado de identificadores con puntajes al lado se lee rápido y decide mal. El formato para pedir ese tipo de información sin que se vuelva una discusión está en cómo responder un cuestionario de seguridad, que sirve igual en la dirección inversa.
Los términos están en el glosario, el orden general de prioridades en la guía de ciberseguridad para PyMEs de LATAM, y el resto de la categoría de identidad en MFA y autenticación.
Preguntas frecuentes sobre los CVE agrupados de Cisco ISE
¿Cuántas vulnerabilidades corrige en realidad la hardening release de ISE?
No se sabe, y ese es el punto. El aviso dice que la revisión interna encontró "multiple internally discovered vulnerabilities" y que se agruparon en seis identificadores por clase de debilidad, pero en ningún lado publica cuántas son. Pueden ser ocho o cincuenta. Lo único que se puede afirmar es que son más de seis, porque si fueran seis no haría falta agrupar.
Si un CVE tiene 10.0, ¿mi instalación tiene una falla de 10.0?
No necesariamente, y acá conviene ser preciso. En estos seis identificadores el puntaje es, según Cisco, el de la falla más severa dentro de esa categoría. Que exista una falla de 10.0 en el grupo no dice que sea explotable en tu configuración, ni cuál de las fallas agrupadas es la que llega a ese número. Para las agrupadas, el puntaje es un techo de la clase. Distinto es CVE-2026-76460, que sí es una falla puntual con 10.0 y explotación confirmada.
¿Está mal lo que hizo Cisco?
Es un intercambio, no una infracción, y tiene un lado defendible: las fallas salieron de una revisión propia, se corrigen todas con la misma actualización, y publicar el detalle de cada una le daría a cualquiera un mapa de qué atacar en las versiones sin parchear. Lo que se pierde está del otro lado: la capacidad de contar, de comparar entre productos y de priorizar dentro del grupo. Quien parchea no nota la diferencia; quien mide, sí.
Tengo ISE en la rama 3.0. ¿Qué hago?
Migrar, porque no hay parche. Cisco indica que la versión 3.0 llegó al fin de mantenimiento de software y por eso no recibe la corrección de CVE-2026-76460, que es la falla explotada. Mientras dure la migración, el equipo queda con un bypass de autenticación sin mitigación posible, así que corresponde tratarlo como expuesto: restringir al máximo desde dónde se alcanza su interfaz de administración y vigilar access.log.
¿Cómo sé si intentaron explotar CVE-2026-76460 contra mi ISE?
El camino que publica Cisco es revisar el access.log del equipo buscando nombres de usuario sospechosos, y repetirlo en cada nodo del despliegue si es distribuido. Con la advertencia de siempre en estos casos: un bypass de autenticación que da acceso administrativo también da la posibilidad de tocar registros, así que la ausencia de rastros en el propio equipo no alcanza para descartar. Si el equipo estuvo en una versión vulnerable y alcanzable, conviene cruzar con los registros de red que estén fuera de él.