Cisco NX-OS: los fallos críticos exigen revisar las funciones activas

12 oct 2026, 12:00·2 fuentes

Por InfraCrew Editorial · Criterios editoriales y correcciones

Los avisos de Cisco afectan a NGOAM, MPLS OAM y NX-API. La exposición depende de plataforma, release y configuración; los Nexus en ACI y el caso UCS requieren distinciones concretas.

Dos switches en un armario de red con latiguillos violetas y una etiqueta NX-OS; el distintivo InfraCrew aparece en una cinta organizadora de cables.

Cisco publicó el 7 de octubre varios avisos críticos de NX-OS que permiten ejecución remota de código o interrupciones del equipo bajo configuraciones concretas. Los casos de NGOAM, MPLS OAM y NX-API merecen revisión conjunta, pero no una explicación que convierta a todos los Nexus en el mismo sistema vulnerable. La plataforma, la release instalada y las funciones habilitadas determinan la exposición.

El efecto puede ser importante: los avisos describen código con privilegios root y fallos de procesos capaces de provocar una recarga del dispositivo. Cisco ha publicado correcciones y no declara conocimiento de uso malicioso en estos avisos. Eso permite priorizar el cambio con datos, sin confundir la gravedad potencial con una campaña de explotación confirmada.

NGOAM tiene tres escenarios distintos

Las CVE-2026-76485, CVE-2026-76486 y CVE-2026-76501 afectan a Nexus 3000 y Nexus 9000 en modo NX-OS independiente bajo las condiciones del advisory. La primera necesita NGOAM habilitado. La segunda añade SRv6 o una configuración de NV Overlay con VXLAN EVPN, un VNI asociado a NVE y al menos un VTEP aprendido; la tercera exige NGOAM y SRv6.

NGOAM proporciona funciones de diagnóstico y supervisión de caminos de red. El detalle de las combinaciones importa porque habilitar una función y desplegar todas las condiciones de una vulnerabilidad no son lo mismo. Cisco ofrece comprobaciones de configuración en el aviso y excluye, entre otros, a los Nexus 9000 que funcionan en modo ACI de este grupo concreto.

-InfraCrew dice: El inventario de «modelo y versión» se queda corto cuando el advisory empieza a preguntar también qué funciones encendiste.-

El fabricante indica que, si NGOAM no se necesita, deshabilitarlo elimina el vector de ataque de estos tres fallos. Es una mitigación condicionada a su uso real, no una instrucción para retirar diagnóstico de producción sin evaluar dependencias. Cisco exige valorar el impacto en cada entorno y mantiene la actualización de software como remediación.

MPLS OAM y NX-API no se deben mezclar

CVE-2026-76465 corresponde al procesamiento de mensajes MPLS OAM en Nexus 3000 y Nexus 9000 independientes. Requiere la función MPLS OAM habilitada, que Cisco describe como desactivada por defecto. Los Nexus 9000 con ASIC Silicon One no la soportan y quedan fuera de ese escenario; el advisory explica cómo consultar su estado.

CVE-2026-76471 afecta a NX-API y tiene una salvedad importante. En Nexus 3000 y 9000 independientes, el escenario requiere NX-API habilitada; en UCS 6300 Fabric Interconnects, Cisco describe explotación a través de la API XML de UCS Manager con credenciales de bajo privilegio. Por ese requisito de autenticación, la valoración de impacto para UCS baja a High: el titular «sin autenticar» no se puede aplicar indistintamente.

-InfraCrew dice: Dos equipos pueden compartir CVE y aun así no compartir la misma puerta de entrada. El ticket de cambio agradecerá que se lo cuentes.-

La versión corregida depende de la plataforma

No hay una build universal que resuelva todas las combinaciones de NX-OS. Cisco remite a su Software Checker para identificar la primera release corregida y, cuando corresponde, la que cubre conjuntamente los avisos aplicables a la versión consultada. El propio advisory de NX-API fue actualizado el 8 de octubre, así que conviene trabajar con su revisión vigente.

Cisco ofrece Live Protect shields como mitigación temporal para estos problemas. Su función es cubrir el intervalo hasta una actualización programada; no sustituyen la release corregida. La decisión debe seguir el alcance del producto y la documentación de compatibilidad, evitando asumir que cualquier shield vale para cualquier equipo.

Desde la operación, separar Nexus independiente, ACI y UCS evita ventanas de cambio mal planteadas. La revisión puede comenzar por release y configuración, continuar con el Software Checker y terminar con el impacto previsto sobre conectividad y gestión. El riesgo de un switch no se resume en una cifra CVSS: también depende de la función que procesa el tráfico y de su alcance real.

-InfraCrew dice: La primera versión que tapa este fallo y la primera que tapa todos los fallos no siempre son la misma. Mejor descubrirlo antes de descargar la imagen.-

Diccionario de la Crew

NGOAM — Next Generation Operations, Administration and Maintenance: funciones de diagnóstico y supervisión de conectividad en los escenarios de red admitidos por NX-OS.