Tornar al Blog

L'orquestrador de la teva WAN és a Internet per disseny: el 10.0 de VeloCloud

Una consola, totes les teves seus
CVE-2026-16812 i la lletra petita de centralitzar

El 27 de juliol, Arista va publicar el seu avís de seguretat 0144. A dins hi va CVE-2026-16812, un 10.0 a CVSS: injecció d'ordres de sistema operatiu al VeloCloud Orchestrator, sense credencials de cap mena, i ja explotada quan va sortir el pedaç. CISA el va incloure aquell mateix dia al seu catàleg de vulnerabilitats explotades amb termini federal per al 30 de juliol: tres dies. Però el que ens va fer aixecar el cap no és la nota. És una frase del mateix avís, escrita sense embuts: «El VCO està exposat per defecte. No hi ha cap configuració que pugui evitar aquesta exposició».

Un orquestrador SD-WAN és la consola central des de la qual es configuren, es vigilen i s'actualitzen els equips de totes les seus d'una empresa. És, literalment, el lloc on viu el dibuix sencer de la teva xarxa: què surt per quina línia, quin túnel arriba on, quina política s'aplica a cada delegació. Aquesta concentració és exactament el que es compra quan es compra SD-WAN, i exactament el que avui té un 10.0 a sobre.

Què és la fallada i a qui li toca

El vector CVSS v3.1 és AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, i convé llegir-lo sencer perquè explica la nota. Atac per xarxa, complexitat baixa, sense privilegis previs i sense que cap usuari hagi de fer res; la S:C del final indica canvi d'àmbit, és a dir que l'impacte se surt del component vulnerable. A l'atacant li n'hi ha prou d'arribar per xarxa a la interfície web de l'orquestrador: no necessita credencials de tenant ni d'operador. Arista puntua també un 10.0 a CVSS v4.0.

Afecta les versions on-prem de l'orquestrador: la branca 5.2.x anterior a la 5.2.3.14, la 6.1.x anterior a la 6.1.3.4, la 6.4.x anterior a la 6.4.2.4 i la 7.0.x anterior a la 7.0.0.1. Els edges i les gateways no són vulnerables per si mateixos, amb un matís important: comprometre l'orquestrador pot obrir la porta als edges que gestiona. Arista diu a més dues coses que s'agraeixen i que no sempre es llegeixen en un avís: que la fallada la va descobrir algú de fora i que se sap que s'està explotant, i publica tres adreces IP vistes atacant (8.19.75.217, 206.72.242.124 i 206.72.242.162). El que no hem vist que digui és des de quan ni a quants clients ha arribat.

«Exposat per defecte» no és cap barroeria: és el tracte

La primera reacció de qualsevol amb dues dècades de xarxa a l'esquena és preguntar per què dimonis això és a Internet. La resposta és incòmoda perquè és raonable: hi ha de ser perquè els edges el trobin. Els equips de cada seu truquen a casa des d'on siguin i pel transport que hi hagi, que sovint és una línia de fibra domèstica contractada la setmana passada. L'aprovisionament sense mans (zero-touch provisioning), aquell que t'estalvia enviar algú a una delegació a 300 quilòmetres, consisteix exactament que un equip acabat de treure de la capsa trobi el seu orquestrador tot solet. Un orquestrador amagat darrere de la VPN corporativa no pot rebre una seu que encara no té VPN.

Una altra cosa, i aquí l'avís és més útil del que sembla a primera vista, és que la consola d'administració hagi d'estar igual d'oberta. A la mateixa pàgina, sota l'epígraf de mitigació, Arista recomana restringir l'accés a la interfície web del VCO a xarxes d'administració de confiança, vigilar accessos des de les IP conegudes, vigilar trànsit sortint inesperat de l'amfitrió i repassar l'activitat recent dels administradors. I en la descripció de la fallada aclareix que l'atac requereix accés per xarxa a aquesta interfície web. Són dues superfícies diferents —el canal pel qual les seus activen els seus equips i el plafó on es toca la configuració— i només una ha d'estar oberta a tothom. El «per defecte» del fabricant només és un punt de partida, i gairebé ningú no el mou.

Tot i això, la propietat que fa útil el producte i la que avui el posa al catàleg de CISA continuen sent la mateixa. Al fullet això es ven com una sola consola per a totes les teves seus. A l'avís de seguretat es descriu com «pot comprometre la confidencialitat, la integritat i la disponibilitat de l'orquestrador i de les dades que gestiona». És la mateixa propietat explicada per dos departaments diferents, i totes dues versions són certes.

Que quedi clar, perquè fa dos dies vam publicar el contrari d'un pamflet: això no és cap argument contra l'SD-WAN. Quan vam explicar quan compensa i quan sobra ja vam posar l'orquestrador a la llista de costos que no surten a la demo, i allà continua. Un desplegament amb moltes seus que canvien no es governa a mà, i el dia que cau una línia agraeixes que el steering per aplicació el decideixi una màquina. El que no toca és comprar la centralització sense mirar què passa el dia que algú hi entra.

El núvol del fabricant ja estava pedaçat

Hi ha una línia de l'avís que es llegeix en dos segons i diu molt: «les versions Hosted i Dedicated del VCO ja s'han pedaçat abans que sortís aquest comunicat». És a dir, la instància que opera el fabricant estava coberta quan la resta del món se n'assabentava. Ens sembla el lògic i és el que faríem nosaltres amb la nostra pròpia plataforma: primer tanques el que tens sota control, després avises.

Però si el teu orquestrador és on-prem, aquesta línia mereix un minut. Durant aquest marge, la instància que et vas quedar per tenir el control va ser l'única amb el forat obert, i el rellotge no el vas posar tu. Compte amb la conclusió fàcil de mudar-ho tot al servei gestionat del fabricant: allà guanyes velocitat de pedaçat i perds finestres, visibilitat i decisió sobre on viuen les teves dades, i et queda el mateix problema el dia que el compromès sigui el servei. El punt és més senzill i força més incòmode. «Autogestionat» és una paraula que al contracte sona a llibertat i un dilluns de juliol vol dir torn de guàrdia. Nosaltres triem on-prem sovint i ho defensem; només demanem que al costat d'aquesta decisió hi hagi escrit qui pedaça, en quant temps i amb permís de qui.

Tres dies, i el catàleg et diu l'ordre

27 de juliol del 2026 — Arista publica l'avís 0144 amb el pedaç, reconeix explotació activa i dona tres IP. Aquell mateix dia, CISA afegeix CVE-2026-16812 al seu catàleg de vulnerabilitats explotades conegudes.
30 de juliol del 2026 — termini perquè les agències civils de l'Executiu federal nord-americà ho tinguin resolt, segons la directiva BOD 26-04. Tres dies.
10 d'agost del 2026 — termini de l'altra fallada que CISA va afegir el mateix 27 de juliol: CVE-2025-68686 a FortiOS, un 5.9 de base (Fortinet en publica un 5.3 aplicant mètriques temporals) que exigeix haver compromès abans l'equip. Dues setmanes per a l'una, tres dies per a l'altra.

Aquest termini només obliga l'Administració nord-americana; a una empresa de Sant Fruitós o de Terrassa tant li fa. Serveix igual: t'estalvia la discussió de si això és urgent, perquè algú ja l'ha tinguda per tu i amb més dades. I la comparació entre els dos terminis del mateix dia és una lliçó de priorització gratuïta. CISA ordena per explotació real i per exposició, que és justament el que la puntuació no mesura.

La pregunta útil, doncs, és quant trigues i qui ho pot fer sense convocar ningú. Si la resposta honesta és «depèn de qui estigui de vacances aquesta setmana», aquesta és la troballa del dia, i val força més que el pedaç.

Si va estar exposat, el pedaç no tanca l'incident

Actualitzar a la versió corregida és el primer. El que ve després és el que gairebé ningú no fa: quan una fallada s'explota abans que existeixi pedaç, actualitzar només garanteix que no hi torni a entrar ningú per aquí, i no diu res de qui hi va passar abans. L'avís hi ajuda més del que és habitual. Demana preservar els registres d'accés web del VCO, els d'aplicació, els de sistema i els de base de dades abans de remeiar, i buscar-hi rutes amb components estranys, caràcters codificats, taxes de petició altes, trànsit sortint inesperat de l'amfitrió, execució d'ordres, creació de fitxers o exportacions de base de dades, i canvis de configuració que no corresponguin a cap activitat d'administrador. A sobre d'això: buscar les tres adreces publicades als registres de l'orquestrador i del perímetre, revisar els comptes d'operador i de tenant creats o modificats les últimes setmanes, i rotar credencials, claus d'API i certificats que l'orquestrador guardi per parlar amb els edges. Amb el mateix criteri amb què mirem els zero-days d'un concentrador VPN perimetral: l'aparell que és a la vora es revisa assumint que algú ho va intentar.

I cal dir la part lletja: és guia útil, però no hi ha ni hashes ni signatures, així que no trobar res tampoc no demostra res. També val la pena tenir present què es perd exactament si l'orquestrador va estar en mans alienes. No és el tall de servei, que probablement no n'hi va haver: és que la topologia de la teva xarxa multiseu, les seves polítiques i les seves credencials passen a ser informació coneguda per algú. Això no ho restaura cap còpia de seguretat i no caduca amb el pedaç.

Qui respon per aquesta consola

El producte en qüestió, de passada, ha canviat de mans tres vegades: VMware va comprar VeloCloud el 2017, Broadcom se'l va trobar a dins en comprar VMware, i el juliol del 2025 Arista va tancar la compra del negoci SD-WAN a Broadcom. Mentrestant, les instàncies on-prem han continuat al mateix armari de sempre. Ho portem aquí perquè explica per què a moltes empreses la pregunta «qui respon per aquesta plataforma?» té una resposta que ja ha caducat tres vegades. El patró es repeteix fora d'aquest cas: fa quatre dies escrivíem sobre una altra consola de gestió, i el guió era el mateix.

Per això, quan revisem una xarxa que no hem dissenyat nosaltres, hi ha quatre coses que preguntem sempre i cap no necessita comprar res: què exposa de debò cada consola a Internet i per què ho ha de fer; qui hi pot entrar, des d'on i amb quin segon factor; si un compte nou o un canvi de configuració aixequen una alerta que algú llegeix el mateix dia; i en quantes hores es pot aplicar un pedaç crític amb la decisió d'una sola persona. La centralització no és el problema. El problema és tenir-la i no haver-la mirat mai de cara.

Fonts (verificades): CVE-2026-16812, CVSS v3.1 10.0 (vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) i CVSS v4.0 10.0, versions afectades i corregides, versions Hosted i Dedicated ja pedaçades abans de l'avís, exposició per defecte sense cap configuració que l'eviti, mitigació (restringir la interfície web a xarxes d'administració de confiança, vigilar accessos i trànsit sortint, repassar activitat d'administradors), guia de preservació i revisió de registres, requisit d'accés per xarxa a la interfície web, absència de necessitat de credencials de tenant o operador, accés possible als VeloCloud Edge gestionats, explotació activa i les tres IP: Arista, Security Advisory 0144, 27-07-2026. Alta al catàleg KEV el 27-07-2026 i termini del 30-07-2026 sota la directiva BOD 26-04, més CVE-2025-68686 de FortiOS amb termini del 10-08-2026 (el catàleg no publica puntuació CVSS): CISA, Known Exploited Vulnerabilities Catalog. Puntuació de CVE-2025-68686: 5.9 de base a NVD (font Fortinet PSIRT), 5.3 amb mètriques temporals a l'avís del fabricant. Cobertura i confirmació creuada: BleepingComputer i The Hacker News. VeloCloud, fundada el 2012, va acabar a VMware i d'allà a Broadcom; el juliol del 2025 Arista va tancar la compra del negoci SD-WAN: RCR Wireless, 02-07-2025. El criteri de revisió i les quatre preguntes són nostres.

Quines de les teves consoles són a Internet ara mateix?

A everyWAN som operador amb xarxa pròpia i dissenyem, despleguem i mantenim xarxes i comunicacions multiseu, amb SD-WAN quan el cas ho demana i amb WireGuard i BGP quan no. No som resellers d'una plataforma concreta: si el teu orquestrador sobra, t'ho direm. Fer l'inventari de què exposes i qui ho pedaça costa una reunió.

Parlar amb everyWAN

Etiquetes:

Compartir:

Subscriu-te al nostre butlletí

Per rebre històries del món IT, novetats d'everyWAN i ofertes exclusives per a subscriptors, dona't d'alta a la nostra llista de correu

everyWAN
everyWAN