El orquestador de tu WAN está en Internet por diseño: el 10.0 de VeloCloud

El 27 de julio, Arista publicó su aviso de seguridad 0144. Dentro va CVE-2026-16812, un 10.0 en CVSS: inyección de comandos de sistema operativo en el VeloCloud Orchestrator, sin credenciales de ningún tipo, y ya explotada cuando salió el parche. CISA lo metió ese mismo día en su catálogo de vulnerabilidades explotadas con plazo para el 30 de julio: tres días. Lo que nos hizo levantar la cabeza fue una frase del propio aviso, escrita sin rodeos: «VCO está expuesto por defecto. No hay ninguna configuración que pueda evitar esa exposición».

Un orquestador SD-WAN es la consola central desde la que se configuran, se vigilan y se actualizan los equipos de todas las sedes de una empresa. Es, literalmente, el sitio donde vive el dibujo entero de tu red: qué sale por qué línea, qué túnel llega a dónde, qué política se aplica en cada delegación. Esa concentración es exactamente lo que se compra cuando se compra SD-WAN, y exactamente lo que hoy tiene un 10.0 encima.

Qué es el fallo y a quién le toca

El vector CVSS v3.1 es AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, y conviene leerlo entero porque explica la nota. Ataque por red, complejidad baja, sin privilegios previos y sin que ningún usuario tenga que hacer nada; la S:C del final indica cambio de ámbito, es decir que el impacto se sale del componente vulnerable. Al atacante le basta con llegar por red a la interfaz web del orquestador: no necesita credenciales de tenant ni de operador. Arista puntúa también un 10.0 en CVSS v4.0.

Afecta a las versiones on-prem del orquestador: la rama 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 y la 7.0.x anterior a la 7.0.0.1. Los edges y las gateways no son vulnerables por sí mismos, con un matiz importante: comprometer el orquestador puede abrir la puerta a los edges que gestiona. Arista dice además dos cosas que se agradecen y que no siempre se leen en un aviso: que el fallo lo descubrió alguien de fuera y que se sabe que se está explotando, y publica tres direcciones IP vistas atacando (8.19.75.217, 206.72.242.124 y 206.72.242.162). Lo que no hemos visto que diga es desde cuándo ni a cuántos clientes ha alcanzado.

«Expuesto por defecto» no es una torpeza: es el trato

La primera reacción de cualquiera con dos décadas de red a las espaldas es preguntar por qué demonios eso está en Internet. La respuesta es incómoda porque es razonable: tiene que estarlo para que los edges lo encuentren. Los equipos de cada sede llaman a casa desde donde estén y por el transporte que haya, que muchas veces es una línea de fibra doméstica contratada la semana pasada. El aprovisionamiento sin manos (zero-touch provisioning), ese que te ahorra mandar a alguien a una delegación a 300 kilómetros, consiste exactamente en que un equipo recién sacado de la caja encuentre a su orquestador él solito. Un orquestador escondido detrás de la VPN corporativa no puede recibir a una sede que todavía no tiene VPN.

Otra cosa, y aquí el aviso es más útil de lo que parece a primera vista, es que la consola de administración tenga que estar igual de abierta. En la misma página, bajo el epígrafe de mitigación, Arista recomienda restringir el acceso a la interfaz web del VCO a redes de administración de confianza, vigilar accesos desde las IPs conocidas, vigilar tráfico saliente inesperado del host y repasar la actividad reciente de los administradores. Y en la descripción del fallo aclara que el ataque requiere acceso por red a esa interfaz web. Son dos superficies distintas —el canal por el que las sedes activan sus equipos y el panel donde se toca la configuración— y solo una tiene que estar abierta a todo el mundo. El «por defecto» del fabricante es solo un punto de partida, y casi nadie lo mueve.

Aun así, la propiedad que hace útil al producto y la que hoy lo pone en el catálogo de CISA siguen siendo la misma. En el folleto eso se vende como una sola consola para todas tus sedes. En el aviso de seguridad se describe como «puede comprometer la confidencialidad, la integridad y la disponibilidad del orquestador y de los datos que gestiona». Es la misma propiedad contada por dos departamentos distintos, y las dos versiones son verdad.

Que quede claro, porque hace dos días publicamos lo contrario de un panfleto: esto no es un argumento contra SD-WAN. Cuando explicamos cuándo compensa y cuándo sobra ya pusimos el orquestador en la lista de costes que no salen en la demo, y ahí sigue. Un despliegue con muchas sedes que cambian no se gobierna a mano, y el día que se cae una línea agradeces que el steering por aplicación lo decida una máquina. Lo que no toca es comprar la centralización sin mirar qué pasa el día que alguien entra en ella.

La nube del fabricante ya estaba parcheada

Hay una línea del aviso que se lee en dos segundos y dice mucho: «las versiones Hosted y Dedicated del VCO ya se han parcheado antes de que saliera este comunicado». Es decir, la instancia que opera el fabricante estaba cubierta cuando el resto del mundo se enteraba. Nos parece lo lógico y es lo que haríamos nosotros con nuestra propia plataforma: primero cierras lo que tienes bajo tu control, luego avisas.

Pero si tu orquestador es on-prem, esa línea merece un minuto. Durante ese margen, la instancia que te quedaste para tener el control fue la única con el agujero abierto, y el reloj no lo pusiste tú. Cuidado con la conclusión fácil de mudarlo todo al servicio gestionado del fabricante: allí ganas velocidad de parcheo y pierdes ventanas, visibilidad y decisión sobre dónde viven tus datos, y te queda el mismo problema el día que el comprometido sea el servicio. El punto es más sencillo y bastante más incómodo. «Autogestionado» es una palabra que en el contrato suena a libertad y un lunes de julio significa turno de guardia. Nosotros elegimos on-prem a menudo y lo defendemos; solo pedimos que al lado de esa decisión esté escrito quién parchea, en cuánto tiempo y con permiso de quién.

Tres días, y el catálogo te dice el orden

Ese plazo solo obliga a la Administración estadounidense; a una empresa de Sant Fruitós o de Terrassa le da lo mismo. Sirve igual: te ahorra la discusión de si esto es urgente, porque alguien la ha tenido ya por ti y con más datos. Y la comparación entre los dos plazos del mismo día es una lección de priorización gratis. CISA ordena por explotación real y por exposición, que es justo lo que la puntuación no mide.

La pregunta útil, entonces, es cuánto tardas y quién puede hacerlo sin convocar a nadie. Si la respuesta honesta es «depende de quién esté de vacaciones esta semana», ese es el hallazgo del día, y vale bastante más que el parche.

Si estuvo expuesto, el parche no cierra el incidente

Actualizar a la versión corregida es lo primero. Lo que viene después es lo que casi nadie hace: cuando un fallo se explota antes de que exista parche, actualizar solo garantiza que no vuelva a entrar nadie por ahí, y no dice nada de quién pasó antes. El aviso ayuda más de lo habitual aquí. Pide preservar los registros de acceso web del VCO, los de aplicación, los de sistema y los de base de datos antes de remediar, y buscar en ellos rutas con componentes raros, caracteres codificados, tasas de petición altas, tráfico saliente inesperado del host, ejecución de comandos, creación de ficheros o exportaciones de base de datos, y cambios de configuración que no correspondan a ninguna actividad de administrador. Encima de eso: buscar las tres direcciones publicadas en los registros del orquestador y del perímetro, revisar las cuentas de operador y de tenant creadas o modificadas en las últimas semanas, y rotar credenciales, claves de API y certificados que el orquestador guarde para hablar con los edges. Con el mismo criterio con el que miramos los zero-days de un concentrador VPN perimetral: el aparato que está en el borde se revisa asumiendo que alguien lo intentó.

Y hay que decir la parte fea: es guía útil, pero no hay hashes ni firmas, así que no encontrar nada tampoco demuestra nada. Vale también la pena tener presente qué se pierde exactamente si el orquestador estuvo en manos ajenas. No es el corte de servicio, que probablemente no lo hubo: es que la topología de tu red multi-sede, sus políticas y sus credenciales pasan a ser información conocida por alguien. Eso no lo restaura ninguna copia de seguridad y no caduca con el parche.

Quién responde por esa consola

El producto en cuestión, de paso, ha cambiado de manos tres veces: VMware compró VeloCloud en 2017, Broadcom se lo encontró dentro al comprar VMware, y en julio de 2025 Arista cerró la compra del negocio SD-WAN a Broadcom. Mientras tanto, las instancias on-prem han seguido en el mismo armario de siempre. Lo traemos aquí porque explica por qué en muchas empresas la pregunta «¿quién responde por esta plataforma?» tiene una respuesta que ya ha caducado tres veces. El patrón se repite fuera de este caso: hace cuatro días escribíamos sobre otra consola de gestión, y el guion era el mismo.

Por eso, cuando revisamos una red que no hemos diseñado nosotros, hay cuatro cosas que preguntamos siempre y ninguna necesita comprar nada: qué expone de verdad cada consola a Internet y por qué tiene que hacerlo; quién puede entrar en ella, desde dónde y con qué segundo factor; si una cuenta nueva o un cambio de configuración levantan una alerta que alguien lee el mismo día; y en cuántas horas se puede aplicar un parche crítico con la decisión de una sola persona. La centralización no es el problema. El problema es tenerla y no haberla mirado nunca de frente.

Fuentes (verificadas): 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) y CVSS v4.0 10.0, versiones afectadas y corregidas, versiones Hosted y Dedicated ya parcheadas antes del aviso, exposición por defecto sin configuración que la evite, mitigación (restringir la interfaz web a redes de administración de confianza, vigilar accesos y tráfico saliente, repasar actividad de administradores), guía de preservación y revisión de registros, requisito de acceso por red a la interfaz web, ausencia de necesidad de credenciales de tenant u operador, acceso posible a los VeloCloud Edge gestionados, explotación activa y las tres IPs: Arista, Security Advisory 0144, 27-07-2026. Alta en el catálogo KEV el 27-07-2026 y plazo del 30-07-2026 bajo la directiva BOD 26-04, más CVE-2025-68686 de FortiOS con plazo del 10-08-2026 (el catálogo no publica puntuación CVSS): CISA, Known Exploited Vulnerabilities Catalog. Puntuación de CVE-2025-68686: 5.9 de base en NVD (fuente Fortinet PSIRT), 5.3 con métricas temporales en el aviso del fabricante. Cobertura y confirmación cruzada: BleepingComputer y The Hacker News. VeloCloud, fundada en 2012, acabó en VMware y de ahí en Broadcom; en julio de 2025 Arista cerró la compra del negocio SD-WAN: RCR Wireless, 02-07-2025. El criterio de revisión y las cuatro preguntas son nuestros.