Si administrás un VeloCloud Orchestrator en sitio, la parte que más importa no es que haya una falla nueva: es que la versión con la que lo parchaste en septiembre ya no alcanza.
Las versiones que corrigen CVE-2026-114625 son 5.2.3.18, 6.1.3.10 y 6.4.2.12, según el aviso de Arista. Las que corrigieron la falla de septiembre eran 5.2.3.16 y 6.4.2.8. Son más viejas que las de ahora, así que un orquestador puesto al día hace un mes sigue afectado.
La respuesta práctica: mirá el número de versión completo contra la tabla de abajo, no contra el recuerdo de la última actualización. Y si corrés una versión alojada, incluida la Dedicated, Arista dice que ya las parchó: el que tiene trabajo es quien lo corre en sus propios servidores.
Tres parches en 88 días, cada uno por encima del anterior
La tabla sale de comparar los tres avisos de Arista, y conviene decir que es una comparación hecha acá: ningún aviso dice "esto deja corto al anterior". Lo dicen los números cuando se los pone uno al lado del otro.
El tren 5.2 fue 5.2.3.14 → .16 → .18. El 6.4 fue 6.4.2.4 → .8 → .12. Y el tren 6.1 tiene un detalle propio: el aviso de septiembre no listaba ninguna versión corregida para ese tren —decía que las de otros trenes se agregarían con el tiempo—, y ahora el de octubre sí da una, la 6.1.3.10.
Hay un tren del que no puedo decir nada: el 7.0.x. Los avisos de julio y de septiembre lo listaban entre los afectados y ninguno de los dos llegó a publicar una versión corregida para él; el aviso de octubre directamente no lo menciona en su lista. No sé si es porque dejó de estar afectado, porque cambió de nombre o por otro motivo, así que no afirmo nada sobre el 7.0: si estás en ese tren, eso es una pregunta para el soporte de Arista.
Las 3 fallas de VeloCloud Orchestrator terminan en el mismo lugar
Lo que llama la atención no es que haya tres fallas: es que son de tres clases diferentes —inyección de comandos, validación de entradas e inyección SQL— y las tres terminan en el mismo lugar. El catálogo de CISA usa para las tres, casi palabra por palabra, la misma frase: permiten a un atacante remoto alcanzar funcionalidad interna privilegiada y afectar al host del orquestador.
Eso no se arregla cerrando una puerta. Cuando tres defectos sin relación técnica entre sí desembocan en la misma escalada, lo que está expuesto es el diseño de lo que hay detrás de la interfaz web, no un error puntual.
Y el ritmo se acortó: de la primera a la segunda pasaron 57 días, y de la segunda a la tercera, 31 días. Con una sola muestra de cada intervalo no hay tendencia que valga, así que no digo que se esté acelerando; digo que el hueco entre una y otra se redujo a la mitad y que son 3 en 88 días.
Este sitio cubrió la segunda de las tres el 23 de septiembre, cuando entró junto a fallas de Check Point y F5, en cuatro fallas críticas en un solo día. Ahí ya aparecía el punto de los dos puntajes en escalas distintas, que se repite acá: Arista publica 9,9 en CVSS 3.1 y 9,4 en CVSS 4.0 para la misma falla.
Y vale repetir lo que vengo encontrando todos los días: los seis puntajes de las tres fichas los calculó Arista como CNA. Ninguna de las tres tiene puntaje primario de NVD, aunque las tres figuran en estado "Analyzed". Es el mismo patrón que ayer con Collabora.
Qué cambia en CVE-2026-114625: hace falta una cuenta, y con una de solo lectura alcanza
Esta falla se diferencia de las dos anteriores en un punto que a primera vista parece bueno y en realidad no cambia gran cosa: necesita una sesión válida. Las de julio y septiembre no pedían ninguna credencial; esta sí, y por eso el puntaje baja de 10,0 a 9,9.
Pero el aviso aclara cuál es el rol mínimo que sirve, y ahí se desinfla el consuelo: "Enterprise Read Only", el rol más bajo que existe para un usuario de cliente. Con eso, según Arista, "cualquier usuario autenticado puede obtener privilegios de operador y hacerse pasar por un usuario local 'superuser operator'".
Traducido a lo que hace una empresa de verdad: si le diste a un cliente, a un técnico o a un pasante una cuenta de solo lectura para que mire el estado de su red, esa cuenta es suficiente. No hay un escalón intermedio.
Y hay dos frases del aviso que conviene leer juntas, porque sacan de la mesa la salida fácil: "el VCO está expuesto por defecto" y "no hay configuración que pueda impedir esa exposición". No se arregla con un ajuste.
¿A quién afecta CVE-2026-114625?
A quien corra un VeloCloud Orchestrator en sus propios servidores. El universo real es más chico que el de una falla de WordPress, pero cada equipo afectado pesa mucho más, porque un orquestador de SD-WAN es el que gobierna la conectividad de todas las sedes.
Si sos un proveedor de conectividad o de red administrada, esto es tuyo y es urgente. El VCO es exactamente el tipo de pieza que un proveedor regional opera para decenas de clientes.
Si tu red la administra un tercero, no te toca parchear, pero sí preguntar. Y hoy la pregunta es más específica que "¿están al día?": es en qué versión exacta está el orquestador, porque la respuesta "lo actualizamos el mes pasado" es compatible con estar afectado. Cómo se piden y se dan esas respuestas está en cómo responder un cuestionario de seguridad de un cliente.
Si tenés VeloCloud pero en la versión alojada, incluida la Dedicated, Arista dice que ya están parchadas. No tenés acción.
Si lo que tenés son Edge o Gateway de VeloCloud y no el orquestador, el aviso no los lista como afectados por esta falla.
El riesgo de fondo —que el que te presta un servicio sea la vía de entrada— es el mismo que desarrollé en la falla de N-able N-central que le toca al proveedor de IT.
¿Quién puede ignorar el plazo del 26 de octubre en VeloCloud Orchestrator?
El plazo del 26 de octubre —3 días desde el alta, igual que en las tres fallas— obliga a las agencias federales civiles de Estados Unidos por la directiva que cita el catálogo. Si tenés una PyME en Latinoamérica, no te obliga.
Lo que no se ignora es de dónde viene esta: el aviso dice que "este problema fue detectado por Arista y se sabe que está siendo explotado activamente". No es un hallazgo de un investigador externo que todavía nadie usó; el fabricante lo encontró mirando ataques.
Quien no tenga un VCO en sitio puede cerrar la página. Y quien tenga solo la versión alojada, también: esa parte ya la resolvió el fabricante.
¿Cómo sé si mi VeloCloud Orchestrator fue atacado?
Las indicaciones son del aviso de Arista, no mías, y hay dos niveles.
Lo primero, los registros de acceso web del VCO. Arista pide buscar ahí:
- Componentes de ruta con forma de URL donde no corresponde.
- Caracteres codificados.
- Referencias a servicios locales o internos.
- Tasas de peticiones inusualmente altas.
Lo segundo, dos direcciones para bloquear y buscar, que el aviso publica: 74.82.197.86 y 38.54.50.151. Bloquealas y revisá si aparecen en tus registros.
Y lo tercero, qué más mirar en el host: el aviso pide vigilar actividad saliente inesperada desde el VCO —y considerar bloquear puertos de salida que no se usen—, buscar demonios de puerta trasera y webshells, y revisar la actividad reciente de administradores. Para lo de los demonios y las webshells hace falta algo que mire conducta en el equipo y no solo firmas, que es la diferencia que explico en cuándo se justifica un EDR en una PyME.
Un detalle de procedimiento que el aviso remarca y que se pasa por alto con las apuradas: si sospechás que hubo compromiso, preservá los registros antes de remediar. El aviso nombra los de acceso web, los de la aplicación de backend, los del sistema y los de la base de datos, más las marcas de tiempo del sistema de archivos. Si reinstalás primero, esa información se va.
¿Qué hago si tengo un VeloCloud Orchestrator en sitio?
En este orden:
- Mirá el número de versión completo y comparalo con 5.2.3.18, 6.1.3.10 o 6.4.2.12 según tu tren. No alcanza con recordar que lo actualizaste.
- Si estás por debajo, actualizá. Si tu tren no tiene soporte, el aviso dice que esas versiones no fueron evaluadas y que hay que hablar con el soporte de Arista.
- Hasta que puedas actualizar, limitá el acceso a la interfaz web a redes de administración de confianza. Es la primera mitigación que da el aviso. Cómo dar acceso remoto sin publicar la interfaz está en acceso remoto seguro sin VPN y en la categoría de VPN y acceso remoto.
- Preservá los registros antes de tocar nada, si tenés cualquier sospecha.
- Revisá los indicadores de la sección anterior, incluidas las dos direcciones.
- Repasá quién tiene cuentas en el orquestador, incluidas las de solo lectura, y sacá las que no se usan. En esta falla, una cuenta de lectura es una cuenta suficiente.
- Si encontrás un webshell o un demonio que no pusiste, tratá el equipo como comprometido. Es la lógica de cuando una segunda actualización no alcanza: si hubo ejecución en el host, actualizar no saca lo que quedó escrito.
El encuadre más amplio de qué pedirle a la infraestructura de una PyME está en la guía de ciberseguridad para PyMEs de LATAM.
Una aclaración sobre las fuentes. Lo que sí pude leer: los avisos de seguridad 0199, 0183 y 0144 de Arista, de donde salen las versiones afectadas y corregidas de los tres casos, los puntajes con sus vectores, el rol mínimo, las dos frases sobre la exposición por defecto, la confirmación de explotación activa, las mitigaciones y los indicadores; y las fichas de NVD de las tres CVE más el feed JSON del catálogo KEV, de donde salen fechas, plazos, clases de debilidad y el origen de cada puntaje. La página del aviso 0199 responde 406 por curl desde este entorno; la leí con la otra herramienta de lectura web. Lo que es una comparación mía y no una afirmación de Arista: la tabla de los tres parches y la conclusión de que cada uno deja corto al anterior. Ningún aviso lo dice; sale de poner los números en una fila. Lo que no pude determinar: la situación del tren 7.0.x, que los avisos de julio y septiembre listaban como afectado sin llegar a publicar una versión corregida y que el de octubre no menciona. Lo que no incluyo: ninguna descripción de la petición que dispara la inyección. Las dos direcciones IP van porque el fabricante las publica para bloquear y buscar en registros.
Preguntas frecuentes sobre CVE-2026-114625 en VeloCloud Orchestrator
Actualicé el orquestador en septiembre. ¿Estoy cubierto?
No. Las versiones que corrigieron la falla de septiembre eran 5.2.3.16 en el tren 5.2 y 6.4.2.8 en el 6.4. Las que corrigen esta son 5.2.3.18, 6.1.3.10 y 6.4.2.12, todas posteriores. Un orquestador que quedó en 5.2.3.16 o en 6.4.2.8 está por debajo de la versión que corrige CVE-2026-114625 y sigue afectado. Es la razón por la que conviene mirar el número completo y no la fecha de la última actualización.
Mis usuarios solo tienen permisos de lectura. ¿Eso me protege?
No, y es el punto más importante de esta falla. El aviso de Arista dice que el rol mínimo que sirve para explotarla es "Enterprise Read Only", el más bajo que hay para un usuario de cliente, y que a partir de ahí cualquier usuario autenticado puede obtener privilegios de operador y hacerse pasar por un "superuser operator" local. Una cuenta de solo lectura entregada a un cliente o a un técnico es suficiente. Por eso conviene revisar quién tiene cuentas y dar de baja las que no se usan.
¿Puedo cerrar la exposición con alguna configuración?
No del todo, y el aviso es explícito: dice que el VCO está expuesto por defecto y que no hay configuración que pueda impedir esa exposición. Lo que sí recomienda, como mitigación mientras no puedas actualizar, es restringir el acceso a la interfaz web a redes de administración de confianza. Eso reduce quién puede llegar, pero no desactiva la falla: la salida real es la versión corregida.
¿Me afecta si uso VeloCloud en la nube de Arista?
No, según el aviso. Dice que las versiones alojadas, incluida la Dedicated, fueron afectadas y ya fueron parchadas por Arista. El que tiene que actuar es quien corre el orquestador en sitio. Vale notar la diferencia con el aviso de julio, que en su momento decía que las versiones alojadas y Dedicated estaban siendo parchadas, en presente: ahí el trabajo todavía estaba en curso.
¿Por qué esta falla puntúa 9,9 y las dos anteriores 10,0?
Por el requisito de la cuenta. Las fallas de julio y septiembre no pedían credenciales —el vector dice PR:N— y esta pide una sesión válida, aunque sea de solo lectura, lo que en el vector se escribe PR:L. Esa única diferencia baja el puntaje de 10,0 a 9,9 en CVSS 3.1. También conviene no mezclar escalas: Arista publica además un 9,4 en CVSS 4.0, que es otra regla de cálculo sobre el mismo hecho y no un número comparable con los de la 3.1.