:quality(90):no_upscale()){kind=logo}
Vulnerabilidad del Identity Services Engine de Cisco: la plataforma que controla el acceso a la red se convirtió en la vía de entrada de los atacantes
ESTADO: Vulnerabilidad «zero-day» explotada activamente GRAVEDAD: 7/10 DESTINATARIOS: Responsables de seguridad de la Administración, la Defensa y las infraestructuras críticas
12 de octubre de 2026
·Blog
·Comunicaciones seguras
:quality(90):no_upscale())
Una vulnerabilidad en el Identity Services Engine de Cisco, la plataforma encargada de determinar qué dispositivos y usuarios pueden acceder a una red, permitía a los atacantes eludir por completo esa decisión y obtener el mismo nivel de confianza de root que la plataforma está diseñada para garantizar. Cisco ha confirmado que algunos clientes reales ya se habían visto afectados antes de que existiera un parche, sin que hubiera forma alguna de reducir el riesgo mientras tanto.
¿Qué pasó?
El sistema creado para decidir quién accedía a la red se convirtió en el vector de ataque.
Cisco Identity Services Engine, o ISE, es la plataforma en la que confían muchas redes gubernamentales y empresariales para aplicar las políticas 802.1X y RADIUS, es decir, las normas que determinan qué dispositivos y usuarios pueden conectarse y a qué recursos tienen acceso una vez conectados.1 Una vulnerabilidad revelada este mes, CVE-2026-76460, permitía a un atacante remoto no autenticado eludir por completo esa aplicación de políticas y obtener control de nivel root sobre la propia plataforma.1,2 Ese acceso gozaba del mismo nivel de confianza que la red había delegado en ISE para todos los dispositivos y usuarios conectados. No se trataba de una brecha limitada a un único terminal.
El equipo de seguridad de Cisco afirmó que descubrió que la vulnerabilidad estaba siendo explotada activamente a través de un caso de atención al cliente, lo que significa que algunas organizaciones reales ya se habían visto afectadas antes de que Cisco tuviera listo un parche para distribuir.3 Una vez dentro, un atacante con privilegios de root podía alterar o borrar los propios registros de la plataforma, eliminando así las pruebas en las que normalmente se basaría un equipo de seguridad para detectar e investigar la intrusión.2 Cisco confirmó que no existe ninguna solución provisional para las organizaciones que no puedan aplicar el parche de inmediato. La única forma de reducir el riesgo es completar la actualización.1
La CISA añadió la vulnerabilidad a su catálogo de «Vulnerabilidades explotadas conocidas» el 16 de septiembre de 2026, concediendo a las agencias civiles federales un plazo de tres días para aplicar el parche, y la divulgación se produjo un día después de que Cisco confirmara otra falla que se estaba explotando activamente en su Secure Email Gateway.1,4 Dos fallos explotados activamente, de gravedad máxima o casi máxima, en la infraestructura central en un plazo de 48 horas deberían plantear una cuestión más amplia. ¿En qué medida depende la postura de seguridad de una organización de confiar en que un pequeño número de sistemas con altos privilegios se controlen a sí mismos correctamente, sin una verificación independiente?
Tampoco se trata de un caso aislado para ISE en concreto. La plataforma ha sufrido ataques de máxima gravedad dos años consecutivos, con dos vulnerabilidades distintas con puntuación CVSS de 10,0 reveladas en 2025 y otras nueve vulnerabilidades —tres de ellas críticas— incluidas en esta única versión.4 Una plataforma que obtiene repetidamente la puntuación de gravedad más alta de Internet no es una plataforma en la que se deba confiar en las decisiones de acceso sin disponer de un método independiente para verificarlas.
Lo que descubrieron
Conclusión | Qué significa | Consecuencias operativas | Pregunta abierta |
La vulnerabilidad permitía a un atacante eludir por completo las medidas de control de acceso de Cisco ISE y obtener el mismo nivel de confianza de root que la plataforma normalmente solo concede tras verificar un dispositivo o un usuario. | La seguridad del control de acceso depende de la solidez de la plataforma que lo aplica, y cuando esa misma plataforma puede eludirse, todas las decisiones de acceso posteriores que haya tomado resultan sospechosas. | Las organizaciones no pueden considerar que «el dispositivo haya superado el control de acceso a la red» como prueba de nada, una vez que se ha demostrado que el propio punto de control puede eludirse. | ¿Cómo podría un equipo de seguridad saber si un dispositivo ha obtenido acceso a través de esta vía alternativa en lugar de mediante el proceso de verificación habitual de Cisco, sin disponer de un registro independiente con el que compararlo? |
El aprovechamiento exitoso de esta vulnerabilidad proporcionó a los atacantes acceso de nivel root, incluida la capacidad de modificar o borrar los propios registros de la plataforma. | Las organizaciones del sistema que, en circunstancias normales, habrían comprobado qué ocurrió durante un incidente no podían considerarse una fuente fiable de pruebas en este caso concreto de violación de la seguridad. | La respuesta ante incidentes no puede basarse únicamente en los propios registros del sistema afectado, sino que necesita una fuente independiente y fiable que confirme qué dispositivos tuvieron acceso realmente y en qué momento. | ¿Mantienen las organizaciones afectadas registros de acceso y cumplimiento fuera de la propia plataforma de control de acceso, de modo que una investigación no dependa por completo de un sistema que un atacante podría haber alterado ya? |
Este es el segundo año consecutivo en el que Cisco ISE ha detectado una vulnerabilidad de máxima gravedad, y solo en esta versión se han identificado nueve fallos en ISE, tres de ellos críticos. | Una plataforma única que se encarga del control de acceso de toda una red es un objetivo recurrente, no una cuestión que se resuelva con un parche puntual. | Las organizaciones que verifican el acceso y el cumplimiento únicamente a través de la plataforma objeto del ataque carecen de un control independiente cuando es precisamente esa plataforma la que se ve comprometida. | ¿Habría acortado, en este caso concreto, el tiempo transcurrido entre la intrusión y su detección una verificación continua e independiente del cumplimiento normativo de los dispositivos? |
Por qué es importante
La antigua Asunción | La realidad actual | Respuesta de BlackBerry |
Una vez que un dispositivo o un usuario supera el control de acceso a la red, se puede considerar fiable dicho acceso durante toda la sesión sin necesidad de verificaciones adicionales. | La propia plataforma que lleva a cabo esa verificación puede eludirse por completo, lo que significa que un dispositivo podría obtener acceso sin haber superado legítimamente la comprobación que las organizaciones dan por hecho que ha superado. | BlackBerry®UEM comprueba el cumplimiento de los dispositivos de forma continua, en lugar de considerar que una única decisión de control de acceso es permanente, por lo que el estado de un dispositivo se reevalúa continuamente, en lugar de darse por fiable de forma indefinida tras una sola comprobación. |
Los propios registros de la plataforma de control de acceso constituyen un registro fiable de lo que ha ocurrido en la red. | La explotación de ISE a nivel de root permitió a los atacantes modificar o borrar esos registros, eliminando así las pruebas que un equipo de seguridad normalmente investigaría en primer lugar. | La supervisión independiente y continua del cumplimiento mantiene un registro del estado de los dispositivos al margen de la propia plataforma de control de acceso, por lo que una investigación no se limita a las pruebas que un atacante ya haya podido borrar. |
Un plazo de tres días para aplicar el parche es un tiempo de respuesta suficiente ante una vulnerabilidad crítica en el control de acceso. | Cisco confirmó que los atacantes ya estaban aprovechando la vulnerabilidad antes de que existiera el parche, lo que significa que la exposición real comenzó mucho antes de que empezara a contar el plazo de cumplimiento. | La verificación continua del acceso detecta de inmediato un sistema de alto riesgo sin parches a medida que cambian las condiciones, en lugar de esperar a un análisis programado o a un plazo externo para poner de manifiesto lo que ya es un riesgo real. |
Medidas recomendadas
INMEDIATO | Comprueba que todas las instancias de Cisco ISE e ISE-PIC estén actualizadas a una versión corregida y considera cualquier instancia a la que se pudiera acceder desde Internet y que no estuviera actualizada antes del 16 de septiembre como un posible caso de compromiso de seguridad, y no como un simple olvido en la aplicación de parches. |
INMEDIATO | Compara los registros de acceso propios de ISE con un registro independiente de la actividad de los dispositivos y los usuarios, ya que la explotación a nivel de root incluía la capacidad de manipular los registros de la plataforma. |
A CORTO PLAZO | Reducir la dependencia de una única plataforma de control de acceso como única fuente fidedigna de información sobre quién se encuentra en la red y establecer una capa de verificación independiente. |
A CORTO PLAZO | Pasar de una verificación puntual del cumplimiento de los requisitos de los dispositivos y del acceso, que se realiza una sola vez al establecer la conexión, a un modelo continuo. |
EN CURSO | Realiza un seguimiento de la frecuencia con la que las plataformas de control de acceso e identidad de las que depende tu organización requieren parches de emergencia y considera que un patrón recurrente es una señal para incorporar una verificación independiente, no solo para aplicar los parches más rápidamente. |
La seguridad debe abarcar toda la pila de dispositivos
El control de acceso funciona concentrando la confianza en un pequeño número de sistemas diseñados para tomar esa decisión correctamente en todo momento. Esa concentración es también lo que hace que merezca la pena atacar esos sistemas: si se compromete la plataforma que toma la decisión, todos los dispositivos que haya aprobado hasta ese momento pasan a ser sospechosos de inmediato. Una estrategia de seguridad que depende por completo de que un único sistema se verifique a sí mismo no tiene forma de detectar cuándo ese mismo sistema ha sido comprometido. La verificación continua e independiente del cumplimiento de los dispositivos y del acceso existe precisamente para ese momento, detectando lo que ya no se puede confiar que el propio sistema de control de acceso informe.
Referencias:
(The Hacker News, artículo sobre CVE-2026-76460, 17 de septiembre de 2026).
Explotación activa de una vulnerabilidad en Cisco Identity Services Engine (Agencia de Ciberseguridad de Singapur, aviso sobre la explotación activa de la vulnerabilidad de Cisco ISE, 21 de septiembre de 2026).
Cisco revela otro fallo de día cero que ya ha sido explotado, esta vez con una puntuación perfecta de 10 (The Register, cobertura de las revelaciones consecutivas de vulnerabilidades de día cero por parte de Cisco, 17 de septiembre de 2026).
Cisco corrige una vulnerabilidad de día cero en Perfect-10 ISE y otros nueve fallos [2026] (Tech Insider, análisis de CVE-2026-76460 y del historial de vulnerabilidades de Cisco ISE, 22 de septiembre de 2026).
:quality(90):no_upscale())