El orquestador de tu SD-WAN es la llave de todas tus sedes

El martes 22 de septiembre CISA metió cuatro vulnerabilidades más en su catálogo de las que ya se están explotando. Una de ellas es la CVE-2026-93952, un 10,0 sobre 10 en VeloCloud Orchestrator: el sistema desde el que se configuran todas las sedes de una red SD-WAN. La nota no es lo raro. Lo raro es la condición que pone el fabricante para estar expuesto, y cabe en un renglón.

El aviso de Arista lo dice así: el orquestador está expuesto si está configurada la autenticación por certificado desde el equipo de la sede hacia el orquestador, y hace falta acceso a la parte pública del certificado de autenticación de ese equipo. Nada más. Sin credenciales de operador ni de cliente, sin que ningún usuario tenga que hacer clic en nada, con alcance de red a la interfaz web del orquestador. La clasificación técnica es CWE-20, validación de entrada incorrecta, y el vector del CVSS lleva el S:C que significa que el impacto se sale del componente que falla.

La parte pública de un certificado no es un secreto

Ahí está el nudo. La parte pública de un certificado es, por definición y por diseño, el material que se reparte: se presenta en cada apretón de manos TLS, viaja por la red, aparece en inventarios y en capturas, y está dentro del equipo que tienes colgado en la pared de una tienda a la que entra cualquiera. No es una contraseña que se guarda: es lo que se enseña. Y el requisito para alcanzar funcionalidad privilegiada del plano de control es tener eso.

Un matiz honesto, porque juega en contra de lo que acabamos de decir: en el CVSS v4.0 Arista puntúa el fallo con un 9,5 y no con un 10, y la razón está en el vector: ahí marca la complejidad de ataque como AC:H, alta, mientras que en el v3.1 la marca como baja. El fabricante considera, por tanto, que conseguir el certificado de un equipo concreto tiene un coste. Es razonable. La discusión es exactamente esa: cuánto cuesta de verdad hacerse con algo que por diseño se reparte por toda la red y viaja dentro de un aparato que está en una tienda.

Nuestra lectura, y aceptamos que es una lectura: el fallo concreto se parchea, pero el diseño que lo permite sigue ahí en muchos productos. Un plano de control que acepta hablar de igual a igual con cualquiera que presente material no secreto está apostando todo a una sola capa de validación. Ese es el mismo razonamiento por el que, cuando se parchea una consola de gestión comprometida, el parche cierra la puerta pero no borra lo que el atacante ya se llevó: la configuración de tus sedes, las direcciones, los túneles, las políticas.

El segundo diez en ocho semanas

Conviene decirlo porque lo escribimos nosotros: a finales de julio ya contamos el anterior 10,0 de este mismo orquestador, el del aviso 0144. Dos meses después llega el del aviso 0183. Dos vulnerabilidades de nota máxima en el mismo plano de control, las dos explotadas antes de que hubiera parche para todo el mundo, las dos en el catálogo de CISA con plazo de tres días. A la primera se la llama incidente; a la segunda ya se le puede llamar patrón, y un patrón cambia la conversación que toca tener con el fabricante y con quien te lo gestiona.

Hay algo que sí ha mejorado, y lo decimos con el mismo gusto con el que criticamos: en julio nos quejamos de que el aviso no traía hashes ni firmas con las que ponerse a buscar. Este sí los trae. No arregla el fallo, pero cambia lo que puede hacer el que lo sufre.

«Parchea» no vale como respuesta para todo el mundo

Esto afecta a los despliegues del orquestador on-prem, en tus propias instalaciones, no a los alojados por el fabricante, que según el aviso ya están corregidos junto con los dedicados. Las versiones afectadas son la 5.2.3.15 y anteriores, la 6.1.3.7 y anteriores, la 6.4.2.7 y anteriores y la 7.0.0.2 y anteriores. Hay corrección publicada para la 5.2.3.16 en adelante y para la 6.4.2.8 en adelante. Para las ramas 6.1 y 7.0, el propio fabricante dice que las correcciones llegarán.

Lee eso otra vez si tienes la 6.1 o la 7.0, porque describe una situación concreta: vulnerabilidad de nota máxima, explotación confirmada, en el catálogo de CISA con fecha límite del 25 de septiembre para la administración federal estadounidense por la directiva BOD 26-04 —es decir, mañana—, y sin destino al que actualizar hoy. Pasa más a menudo de lo que se cuenta, y es justo el escenario para el que nadie tiene procedimiento escrito, porque todos los procedimientos empiezan por «aplicar la actualización del fabricante».

Cuando no hay parche, lo que queda es reducir quién llega y comprobar si ya han entrado. El fabricante recomienda restringir el acceso a la web del orquestador a redes de administración de confianza, vigilar tráfico saliente inesperado, revisar los registros de acceso buscando patrones raros y cerrar los puertos de salida que no hagan falta. Y publica indicadores concretos, que es lo que de verdad se puede usar esta mañana:

• Dos direcciones IP para buscar en los registros y bloquear: 142.93.149.77 y 104.248.126.159.
• Tres rastros en el sistema de ficheros: /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond —con MD5 dc78e206eaeadec59fc5801fe4556bd0— y /etc/systemd/system/vc-sysmon.service. El primero empieza por punto, así que no sale en un listado normal. Y ojo al tercero, porque es la unidad de systemd que vuelve a arrancar el binario: si borras el ejecutable y dejas el servicio, has limpiado la mitad. Fíjate en la letra, que se presta a confusión a propósito: el binario es vc-sysmond con d final y el servicio es vc-sysmon sin ella.
• Una cabecera HTTP, x-vc-opt, que si tienes los registros del proxy o del balanceador delante del orquestador se puede buscar hacia atrás.

Un aviso sobre esa lista, porque se usa mal continuamente: encontrar un indicador te dice que te han entrado. No encontrarlo solo te dice que no estás en el grupo de los que dejaron esas huellas concretas. Una comprobación de indicadores dura veinte minutos; una auditoría de compromiso dura días y la hace otra gente.

Si apagas el orquestador ahora mismo, ¿qué deja de funcionar?

Esta es la pregunta que hacemos cuando aparece un aviso así, antes que ninguna otra, y casi nunca tiene respuesta preparada. Determina si lo que tienes delante es solo una urgencia de seguridad o además una urgencia de servicio, y de ahí sale el orden en que se hacen las cosas esta tarde. Hay tres respuestas posibles y las tres llevan a sitios distintos.

Si la respuesta es «no deja de funcionar nada, simplemente no puedo cambiar la configuración hasta que vuelva», tienes margen real: puedes sacar el orquestador de internet esta misma tarde y esperar al parche con la red trabajando. Si es «se caen los túneles entre sedes», la centralización te ha dejado sin margen, y entonces el CVE pasa a segundo plano detrás de un problema de arquitectura que llevaba meses ahí. Y si la respuesta es «no lo sé», tienes un experimento pendiente que va a hacer otro por ti, ahora mismo y sin avisar.

En el fondo es el eje de siempre: el fallo es inevitable, la avería es una decisión de diseño. Un orquestador con un problema es un fallo. Que ese problema pare la operación de doce sedes es una decisión que se tomó meses antes, normalmente sin darse cuenta, el día que se publicó su interfaz de gestión donde no tocaba.

Esto no es un argumento contra SD-WAN

Sería fácil y sería deshonesto. Centralizar el control de la red existe porque resuelve un problema de verdad: cambiar una política en veinte sedes sin entrar en veinte equipos, ver el estado de todas las líneas en una pantalla, levantar una tienda nueva en una tarde. Ese intercambio —más control central a cambio de más dependencia del centro— es legítimo, y lo hemos recomendado. Lo que no es legítimo es firmarlo sin saber que se está firmando.

Ya escribimos sobre cuándo compensa SD-WAN y cuándo sobra, y sobre el hábito de dar por cubierto lo que en realidad era una casilla marcada en la sucursal. Este aviso añade un renglón a esa conversación: el orquestador entra en el inventario de sistemas críticos con el mismo rango que el cortafuegos perimetral o el controlador de dominio, porque tiene el mismo alcance. Si tu proveedor lo trata como «el portal de gestión», hay una diferencia de criterio que conviene resolver antes del siguiente aviso, no durante.

Qué hacemos nosotros con esto

Empecemos por lo que no somos: no vendemos licencias de VeloCloud ni de ningún otro orquestador, y no tenemos ningún interés en que la conclusión de este post sea cambiar de fabricante. Lo que hacemos en SD-WAN es diseñar el reparto: qué decide el centro, qué sigue decidiendo la sede sola, y desde dónde se alcanza la consola. Somos operador con red propia, así que la parte de redes y comunicaciones —el transporte, las rutas, lo que pasa cuando una línea se cae— la miramos junto con la de arriba y no por separado.

Y cuando el aviso ya ha salido y toca mirar registros hacia atrás buscando dos direcciones IP y un fichero con punto delante, eso es ciberseguridad y se hace con el reloj en la mano. Si tienes un orquestador en casa y no sabes en qué rama estás, el comando para averiguarlo tarda menos que leer este párrafo.

Fuentes (consultadas el 24-sep-2026): la descripción de CVE-2026-93952, la puntuación CVSS v3.1 de 10,0 con vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H y CVSS v4.0 de 9,5, la clasificación CWE-20, la condición de exposición relativa a la parte pública del certificado del equipo de sede, las versiones afectadas y corregidas, las mitigaciones y los indicadores de compromiso proceden del aviso de seguridad 0183 de Arista. La incorporación al catálogo de vulnerabilidades explotadas el 22-sep-2026 y la referencia a la directiva BOD 26-04 están en el aviso de CISA de ese día, que incluye otras tres entradas; la fecha límite del 25-sep-2026 figura en la ficha de la entrada dentro del propio catálogo KEV, no en la página del aviso. Lo que este post NO afirma: no tenemos ninguna cifra propia ni de terceros sobre cuántos orquestadores hay expuestos, ni en España ni fuera, y no publicamos ninguna; no hemos analizado la vulnerabilidad ni el código malicioso, nos remitimos a lo que publica el fabricante; el plazo de tres días de la directiva BOD 26-04 obliga a las agencias federales de Estados Unidos, no a una empresa española, y lo citamos como señal de gravedad y no como obligación legal tuya; no afirmamos que los equipos de sede de ningún producto concreto dejen o no de encaminar tráfico si el orquestador no responde, porque eso depende del diseño de cada plataforma y es exactamente la pregunta que decimos que hay que hacerle al fabricante; y la lectura sobre el modelo de confianza de los planos de control es criterio nuestro, no una conclusión de Arista ni de CISA.