Mapping the fix: which Arista VeloCloud Orchestrator builds close CVE-2026-114625
Patch planning for CVE-2026-114625 means one upgrade per release train. Arista maintains separate trains for VeloCloud Orchestrator, and each train receives its own fix. A deployment on 5.2 needs a different build from a deployment on 6.4, and neither is helped by installing the other.
Arista published the details in advisory SA-0199 on 22 October and rated the flaw 9.9. Attackers are exploiting it.
The per-train matrix
| Release train | Affected builds | Fixed builds |
|---|---|---|
| 5.2 | before 5.2.3.18 | 5.2.3.18 and later |
| 6.1 | before 6.1.3.10 | 6.1.3.10 and later |
| 6.4 | before 6.4.2.12 | 6.4.2.12 and later |
Three facts sit outside that table.
Hosted and Dedicated orchestrators were patched by Arista. A customer on those service tiers does not install anything for this flaw, and should confirm the tenant's exposure window with the provider rather than assume no data was touched.
VeloCloud Gateway and VeloCloud Edge are not affected. Neither carries the vulnerable code. That narrows the patch scope to the orchestrator hosts.
The 7.0 train is not on the list. Arista states that any release not listed as affected is not vulnerable, so 7.0 deployments are out of scope for this CVE.
The trap in the previous fixes
Each train had a different build that closed the September flaw, CVE-2026-93952, and an even earlier build for the July flaw, CVE-2026-16812. Those builds are still affected by CVE-2026-114625.
In practice: 5.2.3.16 fixed the September issue on the 5.2 train. It is below 5.2.3.18 and remains exposed. 6.4.2.8 fixed September on 6.4. It is below 6.4.2.12 and remains exposed.
Arista notes that 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 for it, and neither advisory says whether 6.1.3.10 also closes the September flaw. A 6.1 operator upgrading to 6.1.3.10 should get written confirmation from Arista on that second question instead of inferring it.
End-of-support trains
Arista has not evaluated releases that have reached end of support. The advisory directs customers on an unsupported train to Arista's Technical Assistance Center to discuss upgrade options. That is a slower path than a routine maintenance window, and it is worth starting before an incident review forces the question.
Two earlier VCO vulnerabilities were reported as exploited in the space of about three months. Plans that treat old trains as permanently adequate should account for that cadence.
Order of work
A defensible sequence looks like this:
- Inventory every orchestrator host and record its exact build, including standby and lab instances.
- Compare each build against the table for its own train.
- Patch internet-reachable orchestrators first, then internal ones.
- Confirm that partner-managed tenants follow the same build requirement, since partner accounts can administer several customers.
- Re-check builds after the window closes, because partial rollouts are common across multi-tenant estates.
If the window cannot close immediately
Arista's interim measures are the same set published for the earlier flaws: restrict VCO web interface access to trusted administrative networks, monitor for connections from known malicious addresses, watch for unexpected outbound traffic from the VCO host, block outbound ports that normal operations do not need, look for backdoor daemons and webshells, and review recent administrator activity for unexplained changes.
Those steps reduce reachability. They do not remove the SQL injection, and Arista states that no VCO setting prevents the default exposure of the interface.
Verification is part of the patch
The advisory does not say whether upgrading removes access that an attacker already gained. A patched orchestrator that was reachable while unpatched is not automatically a clean orchestrator. The evidence to preserve, per Arista, is the VCO web access logs, backend application logs, system logs, database logs and relevant file-system timestamps. Collect them before remediation overwrites the record.
Sources
- Arista Security Advisory 0199: https://www.arista.com/en/support/advisories-notices/security-advisory/24838-security-advisory-0199
- Arista Security Advisory 0183: https://www.arista.com/en/support/advisories-notices/security-advisory/24765-security-advisory-0183
- The Hacker News report: https://thehackernews.com/2026/10/arista-warns-of-critical-velocloud-sql.html
Top comments (0)