If you run VeloCloud SD-WAN with an on-prem orchestrator, stop reading this and go check your version. Then come back. Disclosure first: I work at Zscaler, and we sell into the branch connectivity space too, so read the architecture argument below as coming from someone with a point of view. The facts are all from public reporting, linked at the bottom.
What Happened
On October 22, Arista published Security Advisory 0199 for CVE-2026-114625, a SQL injection in the on-prem VeloCloud Orchestrator (VCO). CVSS 9.9. Arista detected it and says it is actively exploited.
The scary detail is the starting point. The attacker needs a login, but the lowest one will do: Enterprise Read Only, the most basic built-in tenant role. From there they can impersonate a local "superuser operator" account and get operator privileges over the orchestrator and its data. Low complexity, no user interaction.
Fixed builds are 5.2.3.18, 6.1.3.10, and 6.4.2.12 or later, depending on your release train. VeloCloud Gateway and Edge aren't affected. Arista listed two attacking IPs: 74.82.197.86 and 38.54.50.151.
One trap worth calling out: if you patched in September, you're not covered. Those builds fixed a different bug.
The Pattern
This is the third exploited VCO bug since July, according to public reporting:
- July: CVE-2026-16812, a CVSS 10.0 unauthenticated command injection in the orchestrator's web interface. Actively exploited.
- September: CVE-2026-93952, also exploited per reporting.
- October: CVE-2026-114625, the SQL injection above.
Credit where it's due: Arista caught this one itself, published IPs, and had hosted and dedicated VCO customers patched before the advisory went out. That's the right sequence. But on-prem customers have to do the upgrade themselves, and that's where the window lives.
Why Orchestrators Keep Getting Hit
An SD-WAN orchestrator is the brain of the network. It holds configs, credentials, and device secrets, and it pushes changes to every branch. Arista itself warned back in July that a compromised VCO could give attackers access to the Edge devices it manages. Own the orchestrator and you don't have to break into the branches one at a time.
It's the same lesson as the firewall management interfaces I keep writing about. Management planes are the crown jewels, they end up reachable from places they shouldn't be, and "restrict access to admin networks" is always in the advisory, which means it was never the default. Every vendor ships bugs, mine included. The question is how many people can reach the box with the bug, and who's on the hook to patch it.
If You Run On-Prem VCO
- Upgrade now to the fixed build for your train. The September patch doesn't count.
- Lock the VCO web interface to administrative networks only. Better yet, put it behind Zero Trust access so nobody reaches it without a verified identity and device.
- Audit accounts. Kill dormant ones and investigate any operator-level user nobody can explain, or read-only accounts doing write actions.
- Hunt in the logs for the published IPs, and preserve logs before you remediate.
- If anything looks off, rotate credentials, API tokens, and device secrets the orchestrator stores. Patching doesn't evict someone who's already in.
- If you're on hosted VCO, ask Arista to confirm your patched build in writing.
Bottom Line
A read-only login shouldn't be one SQL query away from running your whole WAN. Patch it, hide it, and start treating every management plane you own as the most attractive target on your network, because attackers already do.
Sources: Cybersecurity News on CVE-2026-114625, BleepingComputer on the July VCO zero-day, and Tech Insider's VCO timeline