Una cuenta de solo lectura basta para controlar VeloCloud Orchestrator

«This issue was detected by Arista and is known to be actively exploited» (Arista detectó este fallo y se sabe que se está explotando activamente). Con esa frase cerró Arista Networks el 22 de octubre de 2026 la descripción de CVE-2026-114625, una inyección SQL en VeloCloud Orchestrator con la que cualquier usuario autenticado, incluido el rol de solo lectura más bajo que existe en el producto, pasa a tener privilegios de operador sobre toda la plataforma SD-WAN. Es el tercer zero-day explotado en ese orquestador desde julio, y CISA lo incorporó a su catálogo KEV el 23 de octubre con plazo de corrección hasta el 26.

Tres zero-days de VeloCloud Orchestrator en cuatro meses

VeloCloud Orchestrator (VCO) es el plano de gestión de VeloCloud SD-WAN, el producto que VMware compró en 2017, que pasó a Broadcom en 2023 y que Arista adquirió en julio de 2025. Desde el orquestador se dan de alta los equipos Edge de cada sede, se distribuyen las políticas de tráfico y se guardan las credenciales y los certificados con los que esos equipos hablan con la plataforma. Quien controla el VCO controla la WAN de la empresa.

En 2026 ese plano de gestión ha acumulado tres avisos de explotación activa. El aviso 0144, del 27 de julio, describía CVE-2026-16812, una inyección de comandos del sistema operativo sin autenticación con CVSS 10,0, y CISA la metió en KEV ese mismo día con plazo hasta el 30 de julio. El aviso 0183, del 22 de septiembre, cubría CVE-2026-93952, otro fallo de validación de entrada con CVSS 10,0 que solo se podía explotar si el VCO tenía configurada la autenticación por certificado de los Edge, y también entró en KEV el mismo día con plazo hasta el 25. En ambos casos Arista escribió que «This issue was discovered externally and is known to be actively exploited» (el fallo se descubrió fuera de la compañía y se sabe que se explota activamente). En el de octubre, el descubrimiento es interno.

Según BleepingComputer, que recopiló el historial en septiembre, Arista ya había parcheado en mayo otro zero-day explotado, CVE-2026-7473, en su sistema operativo EOS para switches. Contando ese, son cuatro fallos con explotación confirmada en lo que va de año para el fabricante y tres para el orquestador heredado de Broadcom.

Qué permite la inyección SQL CVE-2026-114625 con una cuenta de solo lectura

El aviso 0199 clasifica el fallo como CWE-89, neutralización incorrecta de elementos especiales en un comando SQL, y lo sigue con el identificador interno BUG2043622. Arista lo describe como un problema que permite a un atacante remoto acceder a funcionalidad interna privilegiada y afectar al host del VCO. En un sistema afectado, «any authenticated user can gain operator privileges» (cualquier usuario autenticado puede obtener privilegios de operador) y hacerse pasar por el usuario local de superoperador, que tiene acceso a funciones pensadas solo para uso interno y que no deberían ser accesibles de forma remota.

La captura del aviso muestra lo poco que pide el fallo. Para explotarlo hacen falta acceso de red a la interfaz web del VCO y una sesión válida en el portal, y el rol mínimo es Enterprise Read Only, el más bajo de los roles de tenant que trae el producto. No hay interacción de usuario. Eso convierte en vector de ataque cualquier cuenta de cliente, de partner o de consulta que se haya repartido a lo largo de los años, y también cualquier credencial robada en un infostealer o reutilizada de otra brecha.

Las dos puntuaciones no se contradicen. CVSS 4.0 pondera de otra forma el impacto sobre sistemas adyacentes y por eso suele quedar unas décimas por debajo de la 3.1 en fallos con cambio de alcance. NVD recibió el registro el 22 de octubre a las 21:17 UTC y, cuando escribimos esta noticia, el 23 de octubre, lo mantenía en estado Received, con las métricas del fabricante y sin análisis propio todavía.

Por qué el VCO on-prem está expuesto y quién debe parchear

El aviso repite una frase que ya aparecía en los de julio y septiembre: el VCO está expuesto por defecto y «There is no configuration that can prevent the exposure» (no hay ninguna configuración que pueda evitar la exposición). La razón es la propia arquitectura del SD-WAN. Los Edge de cada sede tienen que localizar al orquestador desde cualquier conexión para activarse y recibir configuración, así que la interfaz web del VCO suele mirar a Internet. Ese diseño es común a casi todas las plataformas que explicamos cuando repasamos qué es SASE y por qué el SD-WAN se convirtió en su base, y es la misma lógica que convirtió en objetivo la interfaz de administración de PAN-OS hace una semana.

Las versiones Hosted y Dedicated, que gestiona el propio fabricante, estaban afectadas y Arista dice haberlas parcheado ya. El trabajo queda para quien opera un VCO on-prem en las ramas 5.2, 6.1 y 6.4. La rama 7.0 no figura en la lista de afectadas de este aviso, aunque sí lo estaba en los de julio y septiembre, y el fabricante no explica el motivo. Las versiones fuera de soporte no se han evaluado, así que quien siga en una de ellas tiene que hablar con el TAC de Arista para conocer la vía de actualización. VeloCloud Gateway y VeloCloud Edge no están afectados de forma directa, aunque un orquestador comprometido abre camino hacia ellos.

En España, INCIBE-CERT abrió el 22 de octubre la ficha del CVE en su alerta temprana con gravedad crítica y la descripción pendiente de traducción, como se ve en la captura, y la modificó el 23. A 23 de octubre ninguno de los dos CERT españoles de referencia había publicado un aviso propio sobre el fallo. Tampoco hemos encontrado, a 23 de octubre de 2026, recuentos públicos de Shodan, Censys o Shadowserver sobre cuántos VCO on-prem hay accesibles desde Internet, ni Arista ha dado el número de clientes afectados.

Para inventariar los propios, runZero publicó en septiembre, a raíz del segundo fallo, la huella que identifica la interfaz web del orquestador en su inventario de servicios. Sirve igual para este tercero, porque el producto no ha cambiado.

_asset.protocol:=http AND protocol:=http AND (http.body:"single-spa-application:@velocloud/vco-header" OR last.http.body:"single-spa-application:@velocloud/vco-header")

La cadena single-spa-application:@velocloud/vco-header aparece en el HTML del portal y vale como filtro en cualquier otro escáner que indexe cuerpos HTTP, incluido un Shodan o un Censys con cuenta de pago.

Cómo buscar las huellas de los atacantes en el orquestador

Arista publica dos direcciones IP desde las que ha visto los ataques contra CVE-2026-114625 y pide bloquearlas y buscarlas en los registros. Como en los avisos anteriores, advierte de que no hay un único indicador definitivo de compromiso y de que las direcciones pueden cambiar. La tabla reúne los indicadores de los tres avisos, porque un VCO que no se parcheó en julio o en septiembre puede llevar meses comprometido por cualquiera de los fallos anteriores.

El aviso 0183 añadía una cabecera HTTP, x-vc-opt, que aparece en los logs de nginx cuando se explota el fallo de septiembre. Para el de octubre, Arista pide revisar los registros de acceso web del VCO en busca de componentes de ruta con forma de URL, caracteres codificados, referencias a servicios locales o internos y tasas de peticiones anómalas. Estos comandos recorren los registros de nginx del orquestador buscando las dos IP de octubre, la cabecera de septiembre y los patrones de codificación que describe el fabricante.

grep -hE '74\.82\.197\.86|38\.54\.50\.151' /var/log/nginx/access.log* | head -50
grep -hri 'x-vc-opt' /var/log/nginx/ | head -20
grep -hEi '%27|%22|%3b|%2f%2f|127\.0\.0\.1|localhost' /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
ls -la /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond /etc/systemd/system/vc-sysmon.service 2>/dev/null

Si alguno devuelve resultados, el fabricante pide conservar antes de remediar los registros de acceso web, los de la aplicación, los del sistema y los de la base de datos, junto con las marcas de tiempo del sistema de archivos. Esa misma exigencia la ha hecho suya CISA.

Qué hacer hoy si administras un VeloCloud Orchestrator on-prem

1. Comprueba la versión real que corre el orquestador y actualiza a 5.2.3.18, 6.1.3.10 o 6.4.2.12, o a una posterior de la misma rama. Si estás en 7.0 o en una versión fuera de soporte, abre un caso con el TAC de Arista antes de dar nada por seguro.
2. Mientras no puedas parchear, restringe la interfaz web del VCO a las redes de administración de confianza con listas de control de acceso en el perímetro, y asume que esa medida no cierra el canal de activación de los Edge.
3. Bloquea las direcciones 74.82.197.86 y 38.54.50.151 y busca en los registros tanto esas IP como las de los avisos de julio y septiembre.
4. Revisa todas las cuentas con rol Enterprise Read Only, de partner y de cliente, desactiva las que nadie reclame y fuerza el cambio de contraseña del resto, porque cualquiera de ellas ha bastado para explotar el fallo.
5. Audita la actividad reciente de los operadores en busca de cambios de configuración, nuevas cuentas, exportaciones de base de datos o certificados descargados que nadie reconozca.
6. Vigila el tráfico saliente del host del VCO, bloquea los puertos de salida que no necesite y busca demonios o webshells que no formen parte de la instalación.
7. Si hay indicios de intrusión, conserva los registros y las marcas de tiempo, rota las credenciales y los certificados que gestiona el orquestador, valida el estado de los Edge y restaura el VCO desde una fuente de confianza. Si eres una empresa, el incidente se notifica a INCIBE-CERT, y si administras un VCO en un organismo público, al CCN-CERT.

La entrada del catálogo KEV marca como obligatorio el triaje forense bajo la directiva BOD 26-04 y deja en desconocido el uso del fallo en campañas de ransomware. Es la misma pauta que vimos cuando CISA incluyó en KEV el fallo de FortiOS usado para PEERSTITCH con tres días de plazo. Aplicar el parche sin mirar antes los registros no responde a la pregunta de si alguien ya tenía privilegios de operador en el VCO.

Hacer ese inventario de cuentas es más fácil si los registros del VCO ya llegan a un SIEM central con alertas sobre accesos administrativos, como repasamos en las prácticas para implantar una estrategia SIEM.

Qué cabe esperar tras el tercer aviso de Arista

El aviso no dice cuándo empezaron los ataques, cuántos orquestadores se han visto afectados ni qué hicieron los atacantes después de escalar a operador. Tampoco atribuye la actividad a ningún grupo, y ninguna agencia ni laboratorio lo ha hecho hasta el 23 de octubre. Arista sí deja claro que el fallo lo detectó la propia compañía, a diferencia de los dos anteriores, lo que apunta a que estaba vigilando su plataforma tras los incidentes de julio y septiembre y vio actividad que no cuadraba.

El gráfico compara las puntuaciones que Arista asignó como CNA a los tres fallos. Las dos primeras se quedan en 10,0 bajo CVSS 3.1 porque no exigen credenciales, y la de octubre baja a 9,9 por el requisito de sesión autenticada, con un impacto alto sobre confidencialidad, integridad y disponibilidad y cambio de alcance en los tres casos. Visto en conjunto, el orquestador lleva cuatro meses encadenando fallos de la máxima gravedad.

Hay una lectura que nos parece difícil de evitar. Un atacante que ya tuviese una cuenta de solo lectura en un VCO parcheado el 22 de septiembre contra CVE-2026-93952 ha podido convertirla en control total hasta el 22 de octubre sin que ninguna de las dos correcciones anteriores lo impidiese. Las versiones que cerraron los fallos de julio y septiembre quedan por debajo de los umbrales nuevos, así que el ciclo de parcheo vuelve a empezar para todos. En un producto que ya ha acumulado tres explotaciones activas en cuatro meses, conviene tratar el orquestador como un equipo de borde más, con los mismos controles que aplicamos a una VPN o a un firewall y con un modelo de acceso que no confíe en la red desde la que llega la petición, en la línea de lo que describe el enfoque Zero Trust.

Lo previsible en las próximas semanas es que aparezcan análisis del parche y pruebas de concepto, porque una inyección SQL en una API autenticada se localiza comparando versiones, y que el escaneo se extienda a cualquier VCO cuyo portal siga abierto. El plazo del 26 de octubre que fija CISA no obliga a ninguna empresa española, pero es una medida bastante exacta de cuánto margen cree la agencia que queda.