Arista VeloCloud Orchestrator: exact builds that fix exploited CVE-2026-114625

A per-train patch for an actively exploited flaw

A critical SQL injection in Arista's VeloCloud Orchestrator, tracked as CVE-2026-114625 and given a severity rating of 9.9, is being exploited in the wild. Arista disclosed the details in security advisory SA-0199 on 22 October, and a dev.to write-up mapping the fix highlights the operational catch: the orchestrator is maintained as separate release trains, and each train received its own patch. A deployment on 5.2 needs a different build from one on 6.4, and installing another train's fix accomplishes nothing.

Which builds close the hole

According to the dev.to summary of the advisory:

• 5.2: affected before 5.2.3.18; fixed in 5.2.3.18 and later
• 6.1: affected before 6.1.3.10; fixed in 6.1.3.10 and later
• 6.4: affected before 6.4.2.12; fixed in 6.4.2.12 and later

Three scoping points sit outside that list. Hosted and Dedicated orchestrators were patched by Arista itself, so those customers install nothing, though the write-up recommends confirming the tenant's exposure window with the provider rather than assuming no data was touched. VeloCloud Gateway and VeloCloud Edge carry none of the vulnerable code, which narrows the patch scope to orchestrator hosts. The 7.0 train is unlisted, and Arista reportedly treats any release not named as affected as not vulnerable.

September's fix is not this fix

Each train already received builds for two earlier flaws: CVE-2026-93952 in September and CVE-2026-16812 in July. Those builds remain exposed to the new vulnerability. On the 5.2 train, 5.2.3.16 closed the September flaw but sits below 5.2.3.18; on 6.4, 6.4.2.8 did the same but sits below 6.4.2.12. Teams that treated September's patch as the end of the work need to re-check.

The 6.1 train is messier still. Per the dev.to article, Arista notes the September flaw is fixed only on the 5.2 and 6.4 trains as of 22 October; on 6.1 it affects releases up to 6.1.3.7 and no fixed release is listed. Neither advisory states whether 6.1.3.10 also closes the September issue, and the article's advice is to obtain written confirmation from Arista rather than infer the answer.

Unsupported trains

Arista has not evaluated releases that reached end of support, and the advisory points customers on those trains to its Technical Assistance Center to discuss upgrade options. The write-up frames that as a slower path than a routine maintenance window and worth starting early, a point reinforced by the fact that two earlier orchestrator vulnerabilities were reported as exploited within roughly three months.

If the patch window cannot close immediately

Arista's interim measures repeat its earlier advisories: limit VCO web interface access to trusted administrative networks, monitor for connections from known malicious addresses, watch for unexpected outbound traffic from the orchestrator host, block outbound ports that normal operations do not need, look for backdoor daemons and webshells, and review recent administrator activity for unexplained changes. These steps reduce reachability but do not remove the injection, and, as the article notes, no VCO setting prevents the interface's default exposure.

Upgrading is not the same as recovering

The advisory reportedly does not say whether upgrading removes access an attacker already gained, so an orchestrator that was reachable while unpatched should not be assumed clean after the upgrade. Arista's evidence guidance, as relayed by the write-up, is to preserve VCO web access logs, backend application logs, system logs, database logs and relevant file-system timestamps before remediation overwrites them. The article also proposes an order of work: inventory every orchestrator host including standby and lab instances, compare each build against its own train, patch internet-reachable orchestrators first, confirm that partner-managed tenants meet the same build requirement, and re-check builds once the rollout finishes, since partial rollouts happen often in multi-tenant estates.

Why it matters

The orchestrator is the management plane of an SD-WAN estate, so a compromise there can reach every edge it administers. This is the third exploited VCO vulnerability reported in about three months, which makes "we patched recently" an unreliable safety claim. The per-train patch model creates a concrete trap: builds that fixed September's CVE are still vulnerable now, so safety depends on build-level inventory rather than train-level assumptions. And because patching does not demonstrably evict an intruder, log and timestamp collection belongs in the same maintenance window as the upgrade itself.