L'orquestrador del teu SD-WAN és la clau de totes les teves seus

El dimarts 22 de setembre CISA va ficar quatre vulnerabilitats més al seu catàleg de les que ja s'estan explotant. Una és la CVE-2026-93952, un 10,0 sobre 10 a VeloCloud Orchestrator: el sistema des del qual es configuren totes les seus d'una xarxa SD-WAN. La nota no és el que sorprèn. El que sorprèn és la condició que posa el fabricant per estar exposat, i cap en una ratlla.

L'avís d'Arista ho diu així: l'orquestrador està exposat si està configurada l'autenticació per certificat des de l'equip de la seu cap a l'orquestrador, i cal accés a la part pública del certificat d'autenticació d'aquest equip. Res més. Sense credencials d'operador ni de client, sense que cap usuari hagi de fer clic enlloc, amb abast de xarxa a la interfície web de l'orquestrador. La classificació tècnica és CWE-20, validació d'entrada incorrecta, i el vector del CVSS porta l'S:C que significa que l'impacte se surt del component que falla.

La part pública d'un certificat no és un secret

Aquí hi ha el nus. La part pública d'un certificat és, per definició i per disseny, el material que es reparteix: es presenta a cada encaixada de mans TLS, viatja per la xarxa, apareix en inventaris i en captures, i és dins l'equip que tens penjat a la paret d'una botiga on entra qualsevol. No és una contrasenya que es guarda: és el que s'ensenya. I el requisit per arribar a funcionalitat privilegiada del pla de control és tenir això.

Un matís honest, perquè juga en contra del que acabem de dir: al CVSS v4.0 Arista puntua l'error amb un 9,5 i no amb un 10, i la raó és al vector: hi marca la complexitat d'atac com a AC:H, alta, mentre que al v3.1 la marca com a baixa. El fabricant considera, per tant, que aconseguir el certificat d'un equip concret té un cost. És raonable. La discussió és exactament aquesta: quant costa de debò fer-se amb una cosa que per disseny es reparteix per tota la xarxa i viatja dins d'un aparell que és en una botiga.

La nostra lectura, i acceptem que és una lectura: l'error concret es pedaça, però el disseny que el permet continua allà en molts productes. Un pla de control que accepta parlar d'igual a igual amb qualsevol que presenti material no secret ho està apostant tot a una sola capa de validació. Aquest és el mateix raonament pel qual, quan es pedaça una consola de gestió compromesa, el pedaç tanca la porta però no esborra el que l'atacant ja s'ha endut: la configuració de les teves seus, les adreces, els túnels, les polítiques.

El segon deu en vuit setmanes

Convé dir-ho perquè ho vam escriure nosaltres: a finals de juliol ja vam explicar l'anterior 10,0 d'aquest mateix orquestrador, el de l'avís 0144. Dos mesos després arriba el de l'avís 0183. Dues vulnerabilitats de nota màxima al mateix pla de control, totes dues explotades abans que hi hagués pedaç per a tothom, totes dues al catàleg de CISA amb termini de tres dies. A la primera se l'anomena incident; a la segona ja se li pot dir patró, i un patró canvia la conversa que toca tenir amb el fabricant i amb qui t'ho gestiona.

Hi ha una cosa que sí que ha millorat, i ho diem amb el mateix gust amb què critiquem: al juliol ens vam queixar que l'avís no portava hashos ni signatures amb què posar-se a buscar. Aquest sí que en porta. No arregla l'error, però canvia el que pot fer qui el pateix.

«Pedaça» no val com a resposta per a tothom

Això afecta els desplegaments de l'orquestrador on-prem, a les teves pròpies instal·lacions, no els allotjats pel fabricant, que segons l'avís ja estan corregits juntament amb els dedicats. Les versions afectades són la 5.2.3.15 i anteriors, la 6.1.3.7 i anteriors, la 6.4.2.7 i anteriors i la 7.0.0.2 i anteriors. Hi ha correcció publicada de la 5.2.3.16 en endavant i de la 6.4.2.8 en endavant. Per a les branques 6.1 i 7.0, el mateix fabricant diu que les correccions arribaran.

Llegeix-ho un altre cop si tens la 6.1 o la 7.0, perquè descriu una situació concreta: vulnerabilitat de nota màxima, explotació confirmada, al catàleg de CISA amb data límit del 25 de setembre per a l'administració federal nord-americana per la directiva BOD 26-04 —és a dir, demà—, i sense destinació on actualitzar avui. Passa més sovint del que s'explica, i és just l'escenari per al qual ningú no té procediment escrit, perquè tots els procediments comencen per «aplicar l'actualització del fabricant».

Quan no hi ha pedaç, el que queda és reduir qui hi arriba i comprovar si ja han entrat. El fabricant recomana restringir l'accés al web de l'orquestrador a xarxes d'administració de confiança, vigilar trànsit sortint inesperat, revisar els registres d'accés buscant patrons estranys i tancar els ports de sortida que no calguin. I publica indicadors concrets, que és el que de debò es pot fer servir aquest matí:

• Dues adreces IP per buscar als registres i bloquejar: 142.93.149.77 i 104.248.126.159.
• Tres rastres al sistema de fitxers: /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond —amb MD5 dc78e206eaeadec59fc5801fe4556bd0— i /etc/systemd/system/vc-sysmon.service. El primer comença per punt, així que no surt en un llistat normal. I compte amb el tercer, perquè és la unitat de systemd que torna a arrencar el binari: si esborres l'executable i deixes el servei, n'has netejat la meitat. Fixa't en la lletra, que es presta a confusió expressament: el binari és vc-sysmond amb d final i el servei és vc-sysmon sense.
• Una capçalera HTTP, x-vc-opt, que si tens els registres del proxy o del balancejador davant de l'orquestrador es pot buscar cap enrere.

Un avís sobre aquesta llista, perquè es fa servir malament contínuament: trobar un indicador et diu que t'hi han entrat. No trobar-lo només et diu que no ets al grup dels que van deixar aquelles petjades concretes. Una comprovació d'indicadors dura vint minuts; una auditoria de compromís dura dies i la fa una altra gent.

Si apagues l'orquestrador ara mateix, què deixa de funcionar?

Aquesta és la pregunta que fem quan apareix un avís així, abans que cap altra, i gairebé mai no té resposta preparada. Determina si el que tens al davant és només una urgència de seguretat o a més una urgència de servei, i d'aquí surt l'ordre en què es fan les coses aquesta tarda. Hi ha tres respostes possibles i les tres porten a llocs diferents.

Si la resposta és «no deixa de funcionar res, simplement no puc canviar la configuració fins que torni», tens marge real: pots treure l'orquestrador d'internet aquesta mateixa tarda i esperar el pedaç amb la xarxa treballant. Si és «cauen els túnels entre seus», la centralització t'ha deixat sense marge, i llavors el CVE passa a segon terme darrere d'un problema d'arquitectura que feia mesos que hi era. I si la resposta és «no ho sé», tens un experiment pendent que farà un altre per tu, ara mateix i sense avisar.

En el fons és l'eix de sempre: la fallada és inevitable, l'avaria és una decisió de disseny. Un orquestrador amb un problema és una fallada. Que aquell problema aturi l'operació de dotze seus és una decisió que es va prendre mesos abans, normalment sense adonar-se'n, el dia que es va publicar la seva interfície de gestió on no tocava.

Això no és un argument contra SD-WAN

Seria fàcil i seria deshonest. Centralitzar el control de la xarxa existeix perquè resol un problema de debò: canviar una política a vint seus sense entrar a vint equips, veure l'estat de totes les línies en una pantalla, aixecar una botiga nova en una tarda. Aquest intercanvi —més control central a canvi de més dependència del centre— és legítim, i l'hem recomanat. El que no és legítim és signar-lo sense saber que s'està signant.

Ja vam escriure sobre quan compensa SD-WAN i quan sobra, i sobre l'hàbit de donar per cobert el que en realitat era una casella marcada a la sucursal. Aquest avís hi afegeix una ratlla: l'orquestrador entra a l'inventari de sistemes crítics amb el mateix rang que el tallafoc perimetral o el controlador de domini, perquè té el mateix abast. Si el teu proveïdor el tracta com «el portal de gestió», hi ha una diferència de criteri que convé resoldre abans del pròxim avís, no durant.

Què fem nosaltres amb això

Comencem pel que no som: no venem llicències de VeloCloud ni de cap altre orquestrador, i no tenim cap interès que la conclusió d'aquest post sigui canviar de fabricant. El que fem a SD-WAN és dissenyar el repartiment: què decideix el centre, què continua decidint la seu sola, i des d'on s'arriba a la consola. Som operador amb xarxa pròpia, així que la part de xarxes i comunicacions —el transport, les rutes, què passa quan una línia cau— la mirem juntament amb la de dalt i no per separat.

I quan l'avís ja ha sortit i toca mirar registres cap enrere buscant dues adreces IP i un fitxer amb punt al davant, això és ciberseguretat i es fa amb el rellotge a la mà. Si tens un orquestrador a casa i no saps en quina branca ets, l'ordre per esbrinar-ho triga menys que llegir aquest paràgraf.

Fonts (consultades el 24-set-2026): la descripció de CVE-2026-93952, la puntuació CVSS v3.1 de 10,0 amb vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H i CVSS v4.0 de 9,5, la classificació CWE-20, la condició d'exposició relativa a la part pública del certificat de l'equip de seu, les versions afectades i corregides, les mitigacions i els indicadors de compromís provenen de l'avís de seguretat 0183 d'Arista. La incorporació al catàleg de vulnerabilitats explotades el 22-set-2026 i la referència a la directiva BOD 26-04 són a l'avís de CISA d'aquell dia, que inclou tres entrades més; la data límit del 25-set-2026 consta a la fitxa de l'entrada dins del catàleg KEV, no a la pàgina de l'avís. El que aquest post NO afirma: no tenim cap xifra pròpia ni de tercers sobre quants orquestradors hi ha exposats, ni a Espanya ni fora, i no en publiquem cap; no hem analitzat la vulnerabilitat ni el codi maliciós, ens remetem al que publica el fabricant; el termini de tres dies de la directiva BOD 26-04 obliga les agències federals dels Estats Units, no una empresa espanyola, i el citem com a senyal de gravetat i no com a obligació legal teva; no afirmem que els equips de seu de cap producte concret deixin o no d'encaminar trànsit si l'orquestrador no respon, perquè això depèn del disseny de cada plataforma i és exactament la pregunta que diem que cal fer al fabricant; i la lectura sobre el model de confiança dels plans de control és criteri nostre, no una conclusió d'Arista ni de CISA.