Arista patches a CVSS 10 flaw under active exploitation in VeloCloud Orchestrator
On September 22, 2026, CISA added a CVSS 10 input-validation flaw in Arista’s on-prem VeloCloud Orchestrator to its KEV catalog, exploitable with no credentials. Restrict network access to the VCO web interface and apply the fix before September 25.
September 22, 2026. CISA adds CVE-2026-93952 to its KEV catalog — the list of flaws exploited in the wild — with a federal remediation deadline of September 25, 2026. September 22, 2026. Arista publishes security advisory SA-0183: an input-validation flaw in the on-prem VeloCloud Orchestrator (VCO) lets a remote attacker reach privileged internal functionality “with no tenant or operator credentials”. September 22, 2026. The NVD rates the vulnerability CVSS 10.0, the maximum score. Why it matters: the VCO is the control plane of the SD-WAN — the component that orchestrates the tunnels of every edge router in an enterprise. Compromising it means compromising the routing matrix of an entire distributed network.
The flaw: input validation with no authentication
CVE-2026-93952 is classified CWE-20 (Improper Input Validation). In practice, the VCO accepts input it fails to validate properly, allowing a remote attacker to reach privileged internal functionality and act on the orchestrator host itself. The impact is total: the Arista advisory states that successful exploitation “may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator”.
The CVSS 10.0 score comes from the combination of a network vector (AV:N), low complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), and a scope change (S:C). Translated: no credentials, no clicks, and a blast radius that escapes the single vulnerable component.
Arista is explicit about the exploitation status: the flaw was “discovered externally and is known to be actively exploited”. This is not a theoretical vulnerability waiting for a proof of concept — it is a flaw attackers are already using.
The VCO is the brain of the SD-WAN
To measure the risk, it helps to understand what a VeloCloud Orchestrator is. In an SD-WAN architecture, the VCO is the central component that configures and supervises the Edges (the edge routers deployed across sites) and the Gateways (the traffic concentrators). It distributes routing policy, negotiates tunnels, and manages the authentication certificates between Edge and Orchestrator.
Compromising the VCO is therefore not about compromising one isolated box: it is about taking control of the control matrix that decides the path of all enterprise traffic. An attacker who owns the orchestrator can, in principle, reconfigure tunnels, intercept or divert flows, and read the data the orchestrator handles. That is why the 10.0 score and the KEV listing are not disproportionate.
The product is the direct descendant of VeloCloud by Broadcom — the Arista advisory even labels the affected appliance “VeloCloud Orchestrator On-Prem (Formerly VeloCloud Orchestrator by Broadcom)”. The affected surface is the on-prem VCO: hosted and dedicated instances, by contrast, have “already been patched”, per the advisory.
What exploitation requires, and why that does not reassure
The Arista advisory spells out the conditions required for exploitation. Three elements must align: certificate-based authentication between the VeloCloud Edge and the VCO must be configured; the attacker needs access to the public portion of the Edge authentication certificate; and they need network access to the VCO web interface. No tenant or operator credentials are required.
At first glance, those prerequisites narrow the surface. In reality, they describe the default state of many deployments. Certificate-based Edge-to-VCO authentication is precisely the standard mechanism by which Edges register with the orchestrator. The “public portion” of a certificate is, by definition, meant to travel. And a management web interface exposed — directly on the Internet or on an overly broad management VLAN — is a configuration still common on orchestration appliances.
The lesson is twofold. First, a trivial input-validation bug on a control plane is enough to produce a CVSS 10.0 when the target sits that centrally. Second, the first-order fix is not technical but network-level: Arista recommends restricting access to the VCO web interface to trusted administrative networks only.
There is a wider pattern here. Over the past year, attackers have shifted attention from individual edge devices to the control planes that manage them — the same dynamic behind the string of KEV entries on firewalls and management platforms this autumn. A single orchestrator concentrates trust from hundreds of distributed sites, which is exactly the asymmetry a sophisticated actor wants to exploit: one target, whole-network impact.
Affected versions and the fix
The affected-version table is clean: every release below the fixed thresholds across four version trains is vulnerable.
| Train | Vulnerable versions |
|---|---|
| 5.2.x | 5.2.3.15 and below |
| 6.1.x | 6.1.3.7 and below |
| 6.4.x | 6.4.2.7 and below |
| 7.0.x | 7.0.0.2 and below |
The flaw is tracked internally as BUG1907167 and BUG1937417. Remediation means upgrading past those thresholds, starting with the instances that steer production Edges. Teams running an on-prem VCO should treat September 25, 2026 — the KEV deadline — as a hard date, not only because it binds US federal agencies under directive BOD 26-04.
Even before upgrading, the immediate defense is an access restriction on the firewall in front of the orchestrator:
# Restrict the VCO management web interface to administrative networks only.
# Adjust to the real interface port (443 by default) and your addressing plan.
iptables -A INPUT -p tcp --dport 443 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP If the drop rule is not in place, the interface remains reachable from any network that routes to it — exactly the exploitation condition the advisory describes.
Detecting a compromised VCO
The Arista advisory cautions that there is “no single definitive indicator” of compromise. Detection must therefore rely on a bundle of signals rather than a single signature. Three families of observables deserve close attention.
First, network access. Since exploitation requires access to the VCO web interface, any connection from an unusual IP — a subnet outside the administrative perimeter — is a first-order signal. Orchestrator access logs must be centralized and correlated against the list of allowed networks.
Second, configuration. The VCO distributes routing policy and manages Edge certificates. A compromise often surfaces as unexpected changes: a modified tunnel policy, a newly issued authentication certificate, an unknown Edge appearing in the inventory. Comparing the orchestrator’s state against a known baseline on a schedule is more reliable than waiting for an alert.
Third, the host. The attacker reaches “privileged internal functionality”: an unexpected process, an outbound connection to unusual infrastructure, or a privilege elevation on the orchestrator machine are all signs to treat as a potential compromise, not a performance incident.
The most effective defense remains surface reduction: if the VCO web interface is reachable only from a dedicated bastion or administrative VLAN, the exploitation the advisory describes becomes impractical regardless of software version.
Verdict
CVE-2026-93952 falls into the most dangerous category: an actively exploited zero-day on a network control plane, with a maximum score and credential-free exploitation. If you run an on-prem VCO, apply your version-train fix before September 25, and in the meantime restrict the web interface to administrative networks only — the mitigation the Arista advisory lists first. If you are on a hosted or dedicated instance, confirm with your provider that the patch is deployed, but do not treat the risk as zero: an SD-WAN control plane remains a prime target, as the recent run of edge-device flaws we have been tracking — from F5 BIG-IP to MikroTik RouterOS — has shown.