El 16 de septiembre de 2026 Cisco publicó un aviso de seguridad sobre CVE-2026-76460, que afecta a Identity Services Engine y a ISE Passive Identity Connector. La puntuación base CVSS es 10.0, la máxima que otorga la escala. La causa es un control de autenticación insuficiente en un punto final de la API, y el efecto es que un atacante remoto no autenticado puede llegar a la interfaz de gestión enviando una solicitud manipulada. Cisco afirma sin rodeos que su PSIRT tiene conocimiento de explotación activa y que no hay soluciones alternativas disponibles.

El nombre técnico significa poco para el dueño de una empresa. El significado operativo lo es todo: el equipo afectado no es un servidor de archivos ni una impresora de red. Es el equipo al que el resto de la red pregunta por la identidad de todo aquel que intenta conectarse. Decide que este portátil pertenece a un empleado autorizado, que este teléfono es de un visitante que va a la red de invitados y que este proveedor llega exactamente a un sistema. Cuando cae la autoridad que toma esa decisión, no pierde un servicio. Pierde la base sobre la que se apoyan todos los servicios.

Lo que sabemos realmente

Estos datos proceden del propio aviso de Cisco y del catálogo de vulnerabilidades explotadas conocidas (Known Exploited Vulnerabilities) de CISA, no de artículos de prensa:

  • Productos afectados: Cisco Identity Services Engine e ISE Passive Identity Connector, versiones 3.1 a 3.5.
  • Versiones corregidas: 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 y 3.5 Patch 4.
  • Requisito para la explotación: ninguno. Un atacante remoto no autenticado, una solicitud manipulada a un punto final de la API, sin cuenta y sin contraseña.
  • Estado: explotada activamente según Cisco PSIRT, y añadida al catálogo Known Exploited Vulnerabilities el 16 de septiembre de 2026, con el 19 de septiembre de 2026 como fecha límite de corrección para las agencias federales de Estados Unidos.
  • Solución alternativa: ninguna. La única mitigación que menciona Cisco es restringir el acceso al dispositivo con listas de control de acceso de infraestructura hasta que se aplique el parche.

Tres expresiones de esa lista merecen una pausa: remoto, no autenticado y sin solución alternativa. Cualquier vulnerabilidad a la que le falte una de ellas le deja margen para respirar. Esta no le deja nada salvo parchear o aislar.

Por qué los equipos de identidad son peores que cualquier otro servidor que gestione

En una red corporativa, los sistemas no son iguales en las consecuencias de su compromiso. Si comprometen el servidor de informes, pierde informes. Si comprometen el equipo que gobierna la identidad y el acceso, no ha perdido un dispositivo. Ha perdido el significado de la palabra permiso en toda la red.

Quien obtiene el control administrativo de un sistema así puede, en principio, cambiar las propias políticas: fabricar una identidad autorizada en lugar de intentar burlar un control. Esa es la diferencia esencial. El ataque deja de ser una intrusión que parece anómala en los registros y se convierte en una entrada que parece del todo legítima, porque llegó por la misma puerta en la que usted confía. Es el caso más difícil de detectar, porque la monitorización se basa en la suposición de que todo lo que aprueba el sistema de identidad está, por definición, aprobado.

Añada a eso dónde se ubican estos equipos. Están en el centro de la red y se conectan a todos los segmentos, porque su función lo exige. Así que un punto de apoyo en el equipo es un punto de apoyo en un camino abierto hacia todo lo que hay detrás. Por eso los sistemas de identidad, acceso y autenticación deben estar en lo más alto de la lista de activos críticos y no en el inventario general de equipos de red. Tratamos la misma lógica desde otro ángulo en nuestro artículo sobre el punto único de fallo que nadie mapea.

La lección no va de Cisco

Es fácil leer esto como una noticia sobre un producto de un fabricante. Esa lectura es cómoda e inútil. Cisco publicó la corrección e indicó con claridad el estado de explotación, que es lo que debe hacer un fabricante maduro. Los equipos de seguridad de todos los fabricantes contienen vulnerabilidades, porque son software, y llegarán avisos similares.

La pregunta que hay que llevarse no es si usa Cisco. Es si sabe qué dispositivos y sistemas autentican a los usuarios de su red, en qué versiones están, quién es responsable de parchearlos y cuánto tarda eso en realidad. Una organización que puede responder a esas cuatro preguntas en media hora resuelve este aviso como una tarea de una tarde. Una organización que no sabe quién administra el equipo necesita una semana para llegar a la línea de salida, y toda esa semana es exposición.

Esto es exactamente lo que piden los Controles Esenciales de Ciberseguridad emitidos por la Autoridad Nacional de Ciberseguridad (NCA) en su dominio de gestión de vulnerabilidades: evaluación y detección periódicas de vulnerabilidades, clasificación por gravedad, corrección según esa clasificación y el riesgo asociado, suscripción a fuentes de confianza para conocer nuevas vulnerabilidades y una gestión de parches que verifique la integridad y la eficacia de las actualizaciones en un entorno que no sea de producción antes de aplicarlas. El control que suele fallar no es el parcheo en sí. Es la fuente de confianza: una organización que nunca recibe el aviso del fabricante se entera por un artículo de prensa días después, o no se entera nunca.

La visión de Origami

Desarrollamos sistemas empresariales en lugar de vender hardware de red, y aun así vemos las consecuencias de esto en cada proyecto de integración. Cada vez que conectamos un sistema nuevo a la red de un cliente surge la misma pregunta: quién concede los permisos aquí y dónde queda registrada esa decisión. La observación recurrente es que la parte frágil rara vez es la nueva aplicación o su endurecimiento. Es la capa que la aplicación da por correcta y que nadie inspecciona, porque es antigua y lleva años funcionando en silencio.

Por eso tratamos cualquier componente en la ruta de identidad como parte de la seguridad de la aplicación y no como algo contiguo a ella. Se registra en la lista de activos con su nombre, versión y responsable. Recibe una ventana de mantenimiento acordada de antemano, en lugar de una improvisada el día en que llega un aviso. Y su interfaz de gestión se restringe a una red de administración separada en lugar de ser accesible desde la red general. Son tres prácticas que no necesitan presupuesto nuevo, y marcan la diferencia entre una empresa que lee el aviso de Cisco y sabe qué hacer, y otra que lo lee y empieza por preguntar quién tiene la contraseña del equipo. Forma parte de cómo trabajamos en nuestros servicios.

Cinco preguntas que responder esta semana

Esto no es un programa de seguridad completo. Son cinco respuestas que revelan su preparación para el próximo aviso, porque habrá un próximo aviso.

  • Si usa Cisco ISE o ISE-PIC: ¿en qué versión está y se encuentra entre la 3.1 y la 3.5? Si es así, las versiones corregidas figuran más arriba, y esto es un trabajo urgente, no programado. Hasta que se aplique el parche, restrinja el acceso al dispositivo con listas de control de acceso tal como describe el aviso.
  • Lista de activos: ¿tiene una lista escrita de los sistemas de autenticación y acceso que opera, con sus versiones? Si la respuesta está en la cabeza de una sola persona, no es una lista.
  • Fuente de avisos: ¿quién en su organización está suscrito a los avisos de seguridad de cada fabricante que utiliza? Esa suscripción es gratuita y lleva minutos, y su ausencia suele ser la causa del retraso, más que cualquier falta de herramientas.
  • Tiempo hasta el parche: ¿cuántas horas o días pasaron entre el último aviso crítico que recibió y la aplicación del parche? Anote el número. Esa es su métrica real, y es más honesta que cualquier plan escrito.
  • Interfaces de gestión: ¿las consolas de administración de sus dispositivos críticos son accesibles desde cualquier punto de la red o solo desde una red de gestión definida? Restringir el acceso no elimina la vulnerabilidad, pero convierte un ataque potencialmente abierto a todo internet en uno que primero necesita un punto de apoyo interno.

La conclusión práctica es concreta. Las vulnerabilidades no son un accidente excepcional que sorprende a su empresa; son un acontecimiento recurrente para el que puede ensayar. Lo que separa a una organización que resiste de otra que se detiene no es la ausencia de la falla, sino las horas que transcurren entre la publicación de la corrección y su aplicación.

Fuentes