El 30 de septiembre de 2026, a las 4 de la tarde, hora de Riad, Cisco publicó un aviso de seguridad sobre la CVE-2026-76504 en Cisco Catalyst SD-WAN Manager, el sistema que usan las empresas con varias sucursales para gestionar toda su red de sucursales desde una sola pantalla. La puntuación de gravedad es de 9,8 sobre 10, la explotación no requiere cuenta ni contraseña, Cisco afirma que tuvo conocimiento de una explotación activa durante septiembre y no hay solución alternativa. Ese mismo día, la Autoridad Nacional de Ciberseguridad (NCA) de Arabia Saudí emitió la alerta 2026-7889 con gravedad Crítica, en la que pide a las organizaciones que revisen el aviso y apliquen la actualización.

La pregunta clave no es técnica: ¿quién lo parchea?

Hace dos semanas escribimos sobre una falla explotada en otro equipo de Cisco, el que gobierna la identidad y el acceso, y allí repasamos los fundamentos de la gestión de vulnerabilidades. Esta vez la pregunta más importante no es técnica. Puede que usted no gestione su red de sucursales en absoluto: quizá lo haga por usted un operador de telecomunicaciones o una empresa de TI bajo un contrato de servicio gestionado. En ese caso, ¿quién actualiza el sistema esta noche, quién comprueba si alguien entró antes de la actualización y qué dice su contrato si no ocurre ninguna de las dos cosas?

Qué publicó realmente Cisco

La noticia tiene apenas unas horas, así que estos datos proceden directamente del aviso de Cisco y de la alerta de la NCA, no de reseñas de prensa:

  • Producto: Cisco Catalyst SD-WAN Manager, antes conocido como vManage. El aviso indica que está afectado independientemente de cómo esté configurado.
  • Causa: un manejo incorrecto de la codificación URI en las solicitudes HTTP permite que una solicitud manipulada eluda una regla de autenticación destinada a proteger un endpoint de API concreto, de modo que el atacante llega a la API con los privilegios del usuario administrador.
  • Requisito previo: ninguno. Un atacante remoto y no autenticado, y una puntuación base CVSS de 9,8.
  • Estado: explotada activamente. Cisco PSIRT afirma que tuvo conocimiento de la explotación en septiembre de 2026 y que la falla se descubrió mientras se resolvía un caso de soporte del Cisco Technical Assistance Center.
  • Solución alternativa: ninguna. La corrección consiste en actualizar a una versión corregida.
  • Alerta local: alerta 2026-7889 de la NCA, fechada el 30 de septiembre de 2026. Enumera 14 sectores objetivo, en la práctica todos, desde comercio e inversión, finanzas y economía y sanidad hasta educación, transporte e industria.

Las versiones corregidas, según el aviso:

Rama de versiones actualPrimera versión corregida
Anterior a 20.9Migrar a una versión corregida
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

Fíjese en la primera fila. Quien esté en una versión anterior a 20.9 no se enfrenta a una pequeña actualización, sino a un cambio a otra rama de versiones. Eso requiere planificación, y no puede esperar.

Por qué este sistema en particular

Una red SD-WAN conecta sucursales, almacenes y la sede central a través de las conexiones que haya disponibles, y todo se gestiona desde un sistema central. Ahí es donde se escriben las políticas: qué tráfico va por qué enlace, qué sucursal puede llegar a qué sistema y qué configuración se envía al router de cada sede. Un solo cambio en el centro llega a todas las sucursales. Esa es precisamente su razón de ser.

Esa misma característica es el peligro. Quien llega a la API de este sistema con privilegios de administrador no tiene delante un solo dispositivo, sino la consola que gestiona la configuración de toda la red. El punto de venta de una sucursal, el enlace con el almacén y el acceso al sistema contable desde fuera de la sede pueden funcionar todos sobre una red que controla este sistema. Debe estar en lo más alto de la lista de activos críticos, por muy lejos que parezca de la gestión diaria.

¿La nube de Cisco o su centro de datos? Eso decide quién actúa

El aviso distingue dos formas de operar el sistema, y la diferencia es muy práctica:

  • En la nube de Cisco: el aviso indica que la falla afecta a SD-WAN Manager sea cual sea su configuración y describe dos casos en la nube. En los entornos Cisco Catalyst SD-WAN Cloud Hosted, Cisco ya ha desplegado la mitigación de restricción de acceso, pero una mitigación no es una corrección, así que sigue siendo necesaria la actualización a una versión corregida de la tabla anterior, y conviene preguntar quién la lleva a cabo. En Cisco SD-WAN Cloud (Cisco Managed), la versión 20.15.605 corrige la falla, Cisco afirma que el usuario no tiene que hacer nada y la versión puede comprobarse mediante la función Ayuda de la interfaz del servicio. Solo en este último caso la actualización corre por cuenta del fabricante. Su tarea sigue siendo obtener una confirmación por escrito y pedir que se revisen los registros del periodo anterior.
  • En local, en su sede o en el centro de datos de su proveedor: aquí nadie actualizará el sistema por usted a menos que el contrato lo diga. Hasta la actualización, la mitigación que describe Cisco consiste en restringir el acceso al sistema desde redes no seguras como internet y proteger los componentes de control de SD-WAN detrás de un dispositivo de filtrado, como un cortafuegos.

Así que la primera pregunta no es si usted usa Cisco. Es dónde funciona su sistema de gestión de red y quién es responsable de actualizarlo. Si solo el proveedor conoce la respuesta, esa es la primera brecha que hay que cerrar, y no es técnica.

Una actualización no le dice si alguien entró antes

Cisco supo de la explotación durante septiembre y publicó la corrección el último día del mes. Dicho de otro modo, la falla se estaba explotando antes de que existiera una actualización que aplicar. Actualizar esta noche cierra la puerta. No le dice si alguien ya la cruzó y dejó atrás una cuenta o un cambio de configuración.

Por eso Cisco publicó indicadores que su equipo de TI o su proveedor deben buscar en dos registros concretos del sistema, serviceproxy-access.log y vmanage-server.log:

  • Solicitudes a j_security_check desde direcciones IP desconocidas o no autorizadas.
  • Cualquier carácter codificado como URI en la ruta de la solicitud, como %6a_security_check, donde %6a es la letra j codificada. Así es como el exploit se cuela por delante de la regla de autenticación. Cisco subraya que %6a es solo un ejemplo: puede codificarse cualquier carácter individual de la solicitud, así que el equipo debe buscar todas las variantes codificadas de j_security_check, no solo %6a.
  • En vmanage-server.log en concreto: solicitudes a j_security_check desde direcciones desconocidas hechas para nombres de usuario que empiezan por viptela-reserved-. Son cuentas de servicio integradas del sistema, así que la aparición del nombre en el registro no es en sí misma una señal de compromiso. Lo que importa es el origen desconocido.

Cisco advierte también de que estos indicadores pueden aparecer a veces durante el funcionamiento normal, por lo que hay que compararlos con la actividad habitual de la red antes de sacar conclusiones.

La misma lección surgió esta semana con dos fallas críticas de Citrix NetScaler que la Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA) añadió a su catálogo de vulnerabilidades explotadas conocidas (Known Exploited Vulnerabilities) el 27 de septiembre. CISA dijo que actores maliciosos las están explotando activamente en todo el mundo, animó a las organizaciones a buscar señales de compromiso antes de aplicar parches cuando sea posible y señaló que cualquier organización que sospeche un compromiso debe preservar las pruebas forenses antes de aplicar actualizaciones, porque estas pueden borrar el rastro de lo ocurrido. La regla vale también aquí: compruebe, guarde una copia de los registros y luego actualice, sin dejar que la comprobación se convierta en una excusa para retrasar la actualización varios días.

Si su red es un servicio gestionado: ¿qué dice su contrato?

Los Controles Esenciales de Ciberseguridad de la NCA, edición de 2024, son obligatorios para las entidades gubernamentales y sus empresas vinculadas, y para las entidades del sector privado que poseen, operan o alojan Infraestructura Nacional Crítica. La NCA anima encarecidamente a todas las demás organizaciones del Reino a aplicarlos. Aunque su empresa no esté obligada, son la referencia local más clara de lo que debe figurar en el contrato de cualquier proveedor que gestione parte de su tecnología:

  • En los contratos con terceros cuyo fallo podría afectar a sus datos o servicios, incluidos los acuerdos de nivel de servicio: confidencialidad y eliminación segura de sus datos al final del servicio, procedimientos de comunicación cuando se produce un incidente de ciberseguridad y la obligación del tercero de aplicar sus requisitos y políticas de ciberseguridad (control 4-1-2).
  • En los contratos con proveedores de externalización de TI y de servicios gestionados en particular: una evaluación de riesgos de ciberseguridad, con controles de mitigación confirmados, antes de firmar; y los centros de servicios gestionados de ciberseguridad para supervisión y operaciones que usan acceso remoto deben estar ubicados íntegramente dentro del Reino (control 4-1-3).
  • En la gestión de vulnerabilidades: clasificar las vulnerabilidades por gravedad y corregirlas según esa clasificación, suscribirse a fuentes fiables para conocer nuevas vulnerabilidades y verificar las actualizaciones en un entorno que no sea de producción antes de aplicarlas (control 2-10-3).

Observe lo que no dicen los controles de gestión de vulnerabilidades: no fijan ningún plazo para aplicar una actualización crítica. Esa cifra tiene que escribirse en su propio contrato. De lo contrario, el proveedor parchea cuando puede, no cuando usted lo necesita.

Un mensaje para enviar hoy a su proveedor

No hace falta ser técnico para hacer estas preguntas, ni esperar a una reunión. Pida las respuestas por escrito:

  • ¿Funciona nuestra red con Cisco Catalyst SD-WAN Manager? ¿Y dónde funciona: en la nube de Cisco, en nuestra sede o en su centro de datos?
  • ¿En qué versión está y cuándo se actualizará a la versión corregida, con fecha y hora?
  • ¿Es accesible ahora mismo la interfaz de gestión desde internet? Si es así, ¿han restringido el acceso hasta la actualización?
  • ¿Han revisado los dos registros que nombró Cisco en busca de los indicadores publicados y han guardado una copia antes de actualizar? ¿Qué encontraron?
  • ¿Quién nos informó primero de esta alerta: ustedes o una noticia que leímos? ¿Y cuál es el procedimiento acordado para avisarnos la próxima vez?

La última pregunta es la más importante. Si se enteró de la alerta por un artículo y no por su proveedor, el problema es mayor que esta falla concreta.

La visión de Origami

Construimos sistemas de negocio. No vendemos ni gestionamos equipos de red. Pero cada sistema que construimos para un cliente con varias sucursales funciona sobre una red que no diseñamos nosotros: el punto de venta de la sucursal envía datos al servidor, el almacén actualiza el inventario, la factura electrónica sale hacia la plataforma. Y la respuesta habitual a la pregunta de quién parchea la red es: el proveedor se encarga de todo. Es una respuesta tranquilizadora, y no es una respuesta.

Para un empresario saudí, leemos esta falla como un recordatorio de que externalizar traslada el trabajo pero no la responsabilidad. Un servicio gestionado es la decisión correcta para muchas empresas, siempre que el contrato contenga tres cosas medibles: un plazo establecido para aplicar actualizaciones críticas, aviso por escrito de cada alerta que afecte a sus sistemas y un informe tras cada incidente que diga qué se comprobó y qué se encontró. Esas cláusulas no le cuestan nada a un buen proveedor, y dejan en evidencia a un proveedor débil antes de que lo haga una vulnerabilidad.

En resumen

  • Si usa Cisco Catalyst SD-WAN Manager en su sede o en la de su proveedor, actualizar a la versión corregida es un trabajo urgente, no programado, y las versiones anteriores a 20.9 necesitan pasar a una rama corregida.
  • Hasta la actualización: bloquee el acceso al sistema desde internet y coloque los componentes de control detrás de un cortafuegos, como describe el aviso.
  • Revise ambos registros y guarde una copia antes de actualizar, porque la explotación empezó antes de que se publicara la corrección.
  • Si la red es un servicio gestionado, envíe hoy las preguntas anteriores y, en la próxima renovación, añada al contrato un plazo para las actualizaciones críticas y un procedimiento de notificación.

Fuentes