Cisco Nexus 9000 en la Mira: Falla Crítica en Switches con ASICs Silicon One Permite Ejecución de Código como Root sin Autenticación (CVE-2026-20212, CVSS 9.8)

Fecha de publicación: 3 de septiembre de 2026 Categoría: Seguridad Informática · Vulnerabilidades · Redes de Centros de Datos · Infraestructura Crítica

Contexto: ¿Qué sucedió?

El 2 de septiembre de 2026, Cisco publicó el aviso de seguridad cisco-sa-n9k-s1-rce-EH8dEtr, en el que corrige una vulnerabilidad crítica catalogada como CVE-2026-20212, con una puntuación CVSS de 9.8 sobre 10, prácticamente el techo de la escala. El fallo afecta a diez modelos de la serie Cisco Nexus 9000, los switches que actúan como columna vertebral de tráfico en un enorme número de centros de datos empresariales, específicamente aquellos equipados con procesadores Silicon One: la familia de ASICs (Application-Specific Integrated Circuit, un chip diseñado a la medida para una tarea muy concreta; en este caso, reenviar paquetes de red a altísima velocidad) que Cisco integra en su hardware de conmutación más reciente.

La causa técnica, clasificada bajo CWE-1327 (“enlace a una dirección IP sin restringir”), es, explicada sin jerga, un descuido de exposición de red. Dos puertos TCP, el 43210 y el 43211, quedan accesibles a través de la VRF (Virtual Routing and Forwarding) Layer 3 por defecto del equipo. Una VRF es, en esencia, una partición lógica de la tabla de enrutamiento de un switch: permite que un mismo dispositivo físico mantenga varias “redes virtuales” aisladas entre sí, de modo que, por ejemplo, el tráfico de administración pueda separarse del tráfico de producción que circula por la red. El problema es que, en los equipos afectados, el servicio que escucha en esos dos puertos no quedó restringido a una interfaz de gestión confiable, sino enlazado a cualquier dirección alcanzable a través de la instancia de enrutamiento predeterminada, es decir, potencialmente visible desde cualquier segmento de red con ruta hacia el switch, y no únicamente desde la red de administración que un equipo de operaciones esperaría.

Un atacante que logre alcanzar cualquiera de esos dos puertos puede conectarse directamente al servicio expuesto y enviarle una entrada especialmente manipulada (crafted input). Esa entrada termina ejecutándose como código con privilegios de root, es decir, con el nivel de acceso del superusuario: la cuenta con control absoluto sobre el sistema operativo del dispositivo, capaz de leer, modificar o borrar cualquier cosa en él. Y todo esto sin que el atacante haya presentado jamás una credencial válida ni completado ningún paso de inicio de sesión.

Cisco descubrió el fallo internamente, durante la resolución de un caso de soporte de su Centro de Asistencia Técnica (TAC), y no a raíz de un reporte externo ni de un programa de recompensas por errores. La compañía afirma no tener conocimiento de ningún anuncio público ni uso malicioso del fallo hasta el momento de la publicación del aviso.

La divulgación de CVE-2026-20212 no llegó sola. Ese mismo 2 de septiembre, Cisco publicó también una actualización de endurecimiento (hardening) para IOS XR —el sistema operativo de otra familia de equipos de red, distinta de los Nexus— que agrupa siete identificadores CVE “paraguas” (una práctica de Cisco que consiste en asignar un único CVE por cada categoría de fallos corregidos, puntuándolo según el más severo del lote) y que, según la propia compañía, afecta a todas las versiones de IOS XR sin excepción, sin importar la configuración del dispositivo; dos de esos siete CVEs también alcanzan una puntuación de 9.8. Aunque ese paquete corresponde a routers y no a los switches Nexus de este artículo, su publicación conjunta ilustra el volumen de hallazgos que Cisco procesa bajo su modelo de divulgación quincenal, adoptado explícitamente como respuesta a lo que la propia compañía describe como una aceleración en el descubrimiento de vulnerabilidades.

El Problema: por qué un 9.8 no es una exageración

Una puntuación CVSS (Common Vulnerability Scoring System) de 9.8 no es una cifra decorativa: resume, en una escala de 0 a 10, qué tan fácil es explotar un fallo y qué tan grave es el daño resultante. El vector completo de CVE-2026-20212 es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, y cada componente añade una razón concreta para tomárselo en serio:

En conjunto, esto describe el peor escenario posible para un dispositivo de red: cualquiera que pueda enviarle tráfico a esos dos puertos, sin credenciales ni pasos previos, puede terminar con control total sobre él. Ese control se traduce en ejecución remota de código (RCE, Remote Code Execution): la capacidad de hacer que un sistema corra instrucciones elegidas por el atacante, estando este a kilómetros de distancia, sin haber tocado físicamente el equipo. Cuando esa ejecución ocurre directamente en contexto de root, como en este caso, el atacante no necesita ningún paso adicional de escalada de privilegios; el compromiso inicial y el control absoluto llegan en el mismo movimiento.

El riesgo adicional: la caída del proceso S1HAL

Más allá de la ejecución de código, Cisco advierte que un intento de explotación —incluso uno fallido o mal formado— puede provocar la caída del proceso S1HAL, la capa de software que sirve de puente entre NX-OS (el sistema operativo de estos switches) y el propio ASIC Silicon One. Si ese proceso se cae, el dispositivo completo se reinicia. Esto añade un segundo vector de daño, la denegación de servicio (dejar un sistema o servicio inutilizable para sus usuarios legítimos): un atacante que ni siquiera consiga ejecutar código con éxito puede, aun así, tumbar el switch, con la interrupción de tráfico que eso implica para todo lo que dependa de él.

¿Qué equipos están en riesgo?

La vulnerabilidad afecta exclusivamente a switches Nexus 9000 que incluyan un ASIC Silicon One. Al momento de la publicación, Cisco identificó diez identificadores de producto (PID) vulnerables, verificables con el comando show module:

Vale la pena notar que dos de esos diez, el N9K-C9804 y el N9K-C9808, son chasis modulares de alta capacidad: el tipo de equipo que suele desplegarse en el núcleo de una fábrica de red grande, no en su borde.

Cisco fue explícito sobre lo que no está afectado: el resto de los modelos Nexus 9000 que no aparecen en esa lista, los switches Nexus 9000 que operan en modo Application Centric Infrastructure (ACI), y las series Nexus 3000 y 7000 por completo. Tampoco afecta a otras líneas de producto como los firewalls Firepower y Secure Firewall, los switches MDS 9000 o los fabric interconnects UCS.

En cuanto al software, The Hacker News confirmó, tras contrastar el aviso contra el registro oficial del programa CVE, que 45 versiones distintas de NX-OS, desde la 10.3(1) hasta la 10.6(3s), figuran como afectadas. Cisco no publicó una tabla simple de “versión corregida” para este aviso; en su lugar, remite a la herramienta Cisco Software Checker para que cada organización identifique la ruta de actualización exacta según su plataforma y versión instalada. Una pista relevante: las notas de la versión del propio escudo de mitigación temporal indican que su modo operativo pasa a “no aplica” al actualizarse a NX-OS 10.6(4) o posterior, lo cual sugiere —sin ser una confirmación explícita de Cisco en el aviso mismo— que esa rama ya incorpora la corrección definitiva.

Análisis breve: cuando el objetivo es la plomería de la red

Hay una diferencia estructural entre comprometer un servidor y comprometer un switch troncal de centro de datos. Un servidor comprometido le da a un atacante el control de ese servidor. Un switch central comprometido le da un punto de observación —y potencialmente de manipulación— sobre todo el tráfico que fluye a través de él: las comunicaciones entre aplicaciones, bases de datos y sistemas de almacenamiento que una organización más se esfuerza en proteger en otras capas. Y es, además, una capa de la infraestructura que en la práctica recibe bastante menos vigilancia y monitoreo continuo que los servidores y los equipos de usuario final.

Ese motivo —el valor desproporcionado de la infraestructura de red frente al esfuerzo relativamente contenido de vigilarla— explica por qué el hallazgo de fallos de esta gravedad en equipos troncales no es un evento aislado dentro del propio ecosistema de Cisco. Apenas seis días antes de este aviso, la firma de respuesta a incidentes Sygnia había documentado que el actor de amenazas de presunto nexo chino conocido como Fire Ant —identificado por primera vez en 2025— desplegó implantes hechos a la medida sobre routers IOS XR para suprimir el envío de registros syslog, filtrar la salida de comandos de diagnóstico y sostener un túnel GRE (Generic Routing Encapsulation) oculto, además de capturar paquetes de red y exfiltrarlos hacia servidores FTP externos, y de realizar sondeos contra sistemas conectados asociados a infraestructura crítica. Sygnia no identificó cómo obtuvo el acceso inicial el actor a esos routers, pero la investigación arrancó, según relató la propia firma, a partir de un túnel activo en un equipo sin ninguna configuración ni historial de cambios que lo explicara.

Ninguna de las dos historias prueba que la otra esté relacionada: Fire Ant explotó routers IOS XR por un vector aún no identificado, mientras que CVE-2026-20212 es un fallo distinto en switches Nexus. Pero juntas ilustran el mismo punto de fondo: los equipos que enrutan y conmutan el tráfico de una organización se han convertido en un objetivo de interés sostenido, y comprometer esa capa —silenciosa, poco auditada y con autoridad sobre todo lo que pasa por ella— representa un riesgo que trasciende a la organización individual, extendiéndose a cualquier servicio empresarial que dependa, directa o indirectamente, de esa red.

Consejos de seguridad para administradores de redes

Cisco no reporta explotación activa de CVE-2026-20212 al momento de esta publicación, pero conviene tener presente la advertencia que el propio vicepresidente de seguridad de la información de Cisco, Russ Smoak, hizo en una entrada de blog de junio sobre el nuevo modelo de divulgación de la compañía: “la ventana entre la divulgación y la explotación se ha cerrado efectivamente”. Es decir: la ausencia de explotación conocida hoy describe el presente, no una garantía sobre los próximos días. Con eso en mente, las acciones recomendadas, en orden de prioridad, son:

1. Actualizar a una versión corregida de NX-OS lo antes posible. Dado que Cisco no publicó una tabla sencilla de versión corregida para este aviso, la vía confiable es consultar el Cisco Software Checker con la versión exacta instalada en cada equipo, para obtener la ruta de actualización aplicable a esa plataforma.

2. Verificar la exposición real del parque de switches. Ejecutar show module en cada Nexus 9000 y comparar el identificador de producto (PID) contra la lista de los diez modelos afectados. La exposición no depende de que el switch esté conectado a internet: basta con que los puertos 43210 o 43211 sean alcanzables desde algún segmento interno menos confiable, o ya comprometido, para que el riesgo sea real.

3. Desplegar una iACL (infrastructure access control list, una lista de control de acceso pensada específicamente para proteger al propio dispositivo de red, no para filtrar el tráfico que pasa a través de él) mientras se completa la actualización. Cisco recomienda permitir únicamente el tráfico de gestión y de plano de control estrictamente necesario hacia el equipo, o bien denegar explícitamente el tráfico TCP dirigido a los puertos 43210 y 43211 en la dirección IP configurada localmente. Esta mitigación fue probada con éxito en un entorno de laboratorio de Cisco, aunque la compañía insiste en que cada organización debe validar su aplicabilidad y su posible impacto en el propio entorno antes de desplegarla en producción.

4. Activar el escudo temporal “Live Protect” (identificador lp00031) donde el hardware y la versión lo permitan. Este mecanismo, basado en tecnología eBPF (Extended Berkeley Packet Filter, una función del kernel de Linux que permite ejecutar reglas de seguridad de forma programable sin modificar ni reiniciar el sistema) aplica un control compensatorio validado por Cisco sin necesidad de una ventana de mantenimiento. Solo está disponible para NX-OS 10.6(3) y, mediante un paquete adicional, para 10.6(3s) en los dos modelos Smart Switch; no está soportado en los chasis N9K-C9804 ni N9K-C9808, y su despliegue requiere acceso previo por SSH, Telnet o NX-API. Cisco es enfático en que se trata de un puente temporal, no de un sustituto de la actualización de software.

5. Auditar tráfico y comportamiento anómalos. Vigilar reinicios inesperados de los switches o caídas del proceso S1HAL —posible señal de un intento de explotación fallido o exploratorio—, así como conexiones inusuales dirigidas a los puertos 43210 y 43211 desde segmentos de red que no deberían tener motivo para alcanzarlos.

6. No tratar la ausencia de explotación conocida como sinónimo de ausencia de riesgo. Un fallo de ejecución remota de código sin autenticación, con complejidad de ataque baja y sobre infraestructura de red central, es exactamente el tipo de vulnerabilidad que suele atraer ingeniería inversa rápida una vez hecha pública.

Recapitulando…

CVE-2026-20212 combina tres características que rara vez se presentan juntas: es explotable de forma remota y sin autenticación, otorga ejecución de código con privilegios de root en el mismo paso, y afecta a equipos que constituyen el núcleo de conmutación de un centro de datos, no un servicio periférico. El origen técnico —dos puertos de gestión enlazados a una dirección IP sin restringir, en lugar de a una interfaz de administración confiable— es, al mismo tiempo, sencillo de explicar y contundente en sus consecuencias.

Cisco respondió con una divulgación disciplinada: software corregido, una mitigación de red probada en laboratorio y un escudo temporal de aplicación rápida, todo publicado el mismo día. Para los equipos que operan switches Nexus 9000 con Silicon One, la tarea inmediata no admite demasiados matices: confirmar si el hardware propio aparece en la lista de modelos afectados, aplicar la actualización correspondiente vía Software Checker, y, mientras tanto, cerrar el acceso a los puertos 43210 y 43211 mediante una iACL. La ausencia de explotación reportada hasta hoy es un punto de partida favorable, no una razón para posponer ninguno de esos pasos.

Fuentes consultadas:

• Khandelwal, S. “Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root” — The Hacker News (3 de septiembre de 2026)
• Cisco. “Cisco Nexus 9000 Series Switches Silicon One Remote Code Execution Vulnerability” — Cisco Security Advisory cisco-sa-n9k-s1-rce-EH8dEtr (2 de septiembre de 2026)
• CVE Program. “CVE-2026-20212”
• Centre for Cybersecurity Belgium (CCB). “Warning: Critical Remote Code Execution Vulnerability - NX-OS, Patch Immediately!”
• eSecurity Planet Staff. “Critical Cisco Nexus 9000 Flaw Allows Remote Root Code Execution” — eSecurity Planet (3 de septiembre de 2026)
• Khan, S. “CVE-2026-20212: The Cisco Nexus 9000 Bug That Turns a Management Port Into Root Access” — XHack (3 de septiembre de 2026)