CVE-2026-114625: Arista VeloCloud Orchestrator SQL injection fixed in three builds only

A critical SQL injection in Arista's VeloCloud Orchestrator, tracked as CVE-2026-114625, is repaired in only three specific builds — one per supported release train — which means on-premises operators have to establish exactly which train and build they run before they can say whether a recent patch already protects them. Arista's Hosted and Dedicated offerings were also affected but have already been fixed on the vendor's side. These details come from a triage note published on dev.to, which draws on Arista's Security Advisory 0199, the CVE record, and reporting from The Hacker News.

Affected and fixed builds

According to the note, the CVE record lists three affected ranges:

• 5.2.0 and later, before 5.2.3.18
• 6.1.0 and later, before 6.1.3.10
• 6.4.0 and later, before 6.4.2.12

The corresponding fixed builds are 5.2.3.18, 6.1.3.10 and 6.4.2.12. Anyone on one of those three trains running anything below the listed build is exposed; deployments on a different train fall outside the advisory's scope.

Why recent patching is not enough

The sharpest edge of this advisory is historical. Two earlier VeloCloud Orchestrator vulnerabilities were exploited during 2026 — CVE-2026-16812 in July and CVE-2026-93952 in September, as covered by The Hacker News. An orchestrator upgraded to fix those two issues can still be open to CVE-2026-114625, because the builds that resolved the earlier flaws sit below the new fixed builds on the same train. A host recorded as fully patched in an earlier change record may therefore still be exposed. The note's guidance is blunt: treat past advisories as background, not as evidence of current safety.

Out of scope

VeloCloud Gateway and VeloCloud Edge are not affected by this CVE. Trains absent from the advisory list, including 7.0, are not named as vulnerable. Arista also states that releases past end of support were not evaluated at all, so an unsupported train is better classified as unknown than safe, and escalated to Arista's TAC to work out an upgrade.

Severity and the login requirement

The CVE record assigns CVSS 3.1 at 9.9 and CVSS 4.0 at 9.4. Both land in critical territory, and both describe a flaw that is reachable over the network, exploitable with low complexity, and usable with only low privileges. That last element reshapes the internal conversation: exploitation needs a valid login, so credential hygiene, offboarding of tenants, and shared-account practices move from general housekeeping directly into the exploit path.

Interim mitigations

Where the next maintenance window is still days away, the note recommends network-side measures in the meantime: limit the orchestrator's web interface to known administrative networks, close outbound ports that normal operation does not require, and audit administrator activity for changes nobody expected. These steps cut reachability but do not repair the injection. After the upgrade, check the build actually running on the box rather than taking the change ticket at its word, and search logs from the exposure window for the attacker addresses named in the reporting.

Why it matters

This is as much a patch-management story as a vulnerability story. The flaw itself scores at the top of the severity scale, but the practical risk comes from scoping: three trains, three fixed builds, and earlier patched states that no longer count as patched. With two VeloCloud Orchestrator flaws already exploited in 2026, attackers are demonstrably watching this product line, and the login requirement means identity discipline is now part of the perimeter. Hosted customers were fixed by Arista; on-premises teams are the ones left to act, and the first step is simply knowing which build they run.