Security
Arista's SD-WAN Console Has Its Second Exploited 10.0 in Two Months. Two Release Trains Still Have No Patch
CVE-2026-93952 is a maximum-severity flaw in on-premises VeloCloud Orchestrator, exploited in the wild and now in CISA's catalog with a September 25 deadline. Two of Arista's four supported release trains had no fix when the advisory shipped.
MAI
Arista Networks patched a vulnerability in VeloCloud Orchestrator on September 22 that it says was found outside the company and is already being used in attacks. CVE-2026-93952 carries a CVSS 3.1 score of 10.0, the top of the scale, and it sits in the on-premises build of the console that provisions, configures and monitors every VeloCloud SD-WAN edge an organisation runs. CISA added it to the Known Exploited Vulnerabilities catalog, with federal civilian agencies given until September 25 to remediate.
The score is not the interesting part. The interesting part is that two of the four supported release trains had no fix available when the advisory went out.
Who is affected
The flaw is improper input validation in VeloCloud Orchestrator On-Prem. Arista's advisory puts the affected and fixed builds as follows.
| Release train | Affected | Fixed in |
|---|---|---|
| 5.2 | 5.2.3.15 and earlier | 5.2.3.16 |
| 6.1 | 6.1.3.7 and earlier | No fix at time of advisory |
| 6.4 | 6.4.2.7 and earlier | 6.4.2.8 |
| 7.0 | 7.0.0.2 and earlier | No fix at time of advisory |
Hosted and Dedicated Orchestrator instances — the ones Arista operates — were patched on September 22. Customers running their own are on their own schedule, and for anyone on the 6.1 or 7.0 trains that schedule currently has no date in it.
A precondition that selects for the careful
Exploitation is not unconditional. Arista says an attack requires that the deployment use certificate-based authentication between VeloCloud Edges and the Orchestrator, plus network access to the Orchestrator web interface and the public portion of an Edge's authentication certificate. Deployments that authenticate edges with a pre-shared key are not affected. No Orchestrator credentials are needed.
Read that again, because the shape of it matters. The public half of a certificate is not a secret; it is the half designed to be handed out. And certificate-based edge activation exists precisely because distributing one shared key to every branch appliance is the weaker option. The deployments in the blast radius are, disproportionately, the ones that took the more careful path. That is worth naming plainly rather than filing under bad luck: a precondition that maps onto the hardened configuration inverts the usual assumption that the better-run estate is the safer one.
Why the orchestrator is the wrong thing to lose
An SD-WAN orchestrator is not another server on the network. It is the control plane for the WAN: routing policy, tunnel configuration, firmware, credentials and telemetry for every edge in the fleet, usually including the ones in offices with no local IT. Reporting on the advisory describes successful exploitation as reaching privileged internal functionality on the Orchestrator host, which puts the managed edges downstream of it in question as well. A compromise here is not one box; it is the machine that tells the other boxes what to do.
Arista's advisory says the issue is "known to be actively exploited" and does not say when attacks began, how many customers were hit, or who is behind them. That silence is itself operationally relevant: without a start date, no defender can scope a hunt by saying anything happening before date X is out of range.
What to do this week
Patch to 5.2.3.16 or 6.4.2.8 if you are on those trains. If you are on 6.1 or 7.0, the only control available is the one Arista names in the advisory: restrict access to the Orchestrator web interface to trusted networks, and treat that restriction as the fix until a build exists. Then review administrator activity for changes nobody made.
For detection, Arista published indicators: two file paths dropped on compromised hosts, /usr/local/sbin/.vcnode.js and /usr/local/sbin/vc-sysmond; an x-vc-opt HTTP header appearing in nginx logs; and two addresses seen in attacks, 142.93.149.77 and 104.248.126.159. Absence of those is not a clean bill of health, but their presence settles the question.
The second one in two months
This is not VeloCloud Orchestrator's first maximum-severity exploited bug this quarter. In late July, CVE-2026-16812 — also CVSS 10.0, also exploited in the wild, also added to CISA's catalog under the three-day tier of BOD 26-04 — hit the same product, and that one needed no particular configuration at all.
Two exploited 10.0s in the same management plane inside two months is not a run of bad luck; it is a statement about how much attack surface that interface presents and how many of them are reachable from more of the internet than their owners think. The patch is the urgent task. The durable one is making sure the console that controls the WAN is not something an unauthenticated stranger can reach at all.
Sources: Arista Security Advisory 0183 · BleepingComputer · The Hacker News · SecurityWeek on CVE-2026-16812 · CISA Known Exploited Vulnerabilities Catalog