This issue has been assessed as critical severity. Review affected configurations immediately.
Overview
CVE-2026-16812 is a critical OS command injection vulnerability in Arista VeloCloud Orchestrator (VCO), the centralised management platform for VeloCloud SD-WAN deployments. Assigned a CVSS 3.1 score of 10.0 — the framework’s maximum — the vulnerability enables unauthenticated remote attackers to execute arbitrary commands on the orchestrator. Active exploitation was confirmed in late July 2026; CISA added it to the Known Exploited Vulnerabilities catalog with an immediate remediation recommendation.
VeloCloud Orchestrator is not a standalone appliance. It is the administrative brain of an entire SD-WAN estate: it manages configuration distribution, policy enforcement, and operational visibility for VeloCloud edge devices deployed across branch offices, data centres, and cloud gateways. Compromise of the orchestrator gives an attacker authority over every edge device it manages.
What Is VeloCloud Orchestrator?
Arista VeloCloud is an SD-WAN platform used primarily by enterprises managing geographically distributed networks. VeloCloud Orchestrator (VCO) is the on-premises control plane that:
- Configures and distributes network policies to VeloCloud Edge devices at branch locations
- Monitors WAN link performance, uptime, and traffic across the managed estate
- Manages IPsec and overlay tunnel configurations between sites
- Provides an operator portal for day-to-day network management
Organisations using VeloCloud Orchestrator on-premises typically have it integrated with their network management workflows, and it holds credentials, configuration, and routing policies for their entire wide-area network. It is, effectively, the keys to the WAN.
Technical Analysis
Vulnerability type: OS Command Injection (CWE-78)
Authentication requirement: None — exploitation requires no valid credentials or session tokens.
Root cause: The orchestrator exposes management API endpoints accessible over HTTP/HTTPS. Certain endpoints accept user-supplied parameters that are passed to OS command execution contexts without adequate sanitisation. An attacker supplying crafted input through these endpoints can inject and execute arbitrary commands with the privileges of the VCO service process.
Exploitation pattern: Attackers are observed scanning for publicly accessible VeloCloud Orchestrator endpoints, delivering payloads via HTTP POST or GET requests to vulnerable API endpoints, and leveraging the resulting command execution to establish persistence (web shells, reverse shells) or further compromise the environment.
Affected versions: Only VeloCloud Orchestrator On-Premises is affected. Cloud-hosted VCO instances managed by VMware/Broadcom’s cloud infrastructure received patches through the vendor’s update process and do not require customer action for the cloud-managed version.
| VCO Version | Status |
|---|---|
| Prior to 5.2.3.14 | Vulnerable |
| Prior to 6.1.3.4 | Vulnerable |
| Prior to 6.4.2.4 | Vulnerable |
| Prior to 7.0.0.1 | Vulnerable |
| 5.2.3.14 and later | Patched |
| 6.1.3.4 and later | Patched |
| 6.4.2.4 and later | Patched |
| 7.0.0.1 and later | Patched |
Impact Assessment
Immediate impact: An unauthenticated attacker who successfully exploits CVE-2026-16812 has command execution on the VCO host with service-level privileges. From that position, attackers can:
- Dump VCO database contents, including configuration for all managed Edge devices, VPN credentials, and authentication material
- Push modified configurations to VeloCloud Edge devices across the entire managed estate
- Redirect network traffic or disable WAN links by modifying SD-WAN policy rules
- Establish persistent backdoors on the orchestrator itself (web shell, scheduled task, or modification of VCO service components)
- Use the orchestrator as a pivot point to access management interfaces of other infrastructure in the same network
Secondary impact — managed edge devices: VeloCloud Edge devices receive their configuration from the orchestrator. An attacker controlling VCO can push arbitrary configurations to all managed edges simultaneously, affecting routing, firewall rules, and overlay tunnel configurations across every branch and site in the SD-WAN. This is the network-infrastructure equivalent of domain controller compromise: gaining control of the management plane extends adversary reach to every managed endpoint.
Exploitation context: The active exploitation pattern observed (scanning for accessible endpoints, automated payload delivery) is consistent with initial access brokers and ransomware pre-positioning. SD-WAN management infrastructure is a high-value target for ransomware operators because it provides rapid lateral movement capability and can be used to disable network segmentation that would otherwise contain an intrusion.
Who Is Exposed
Internet-facing VCO instances: Any VeloCloud Orchestrator with its management interface accessible from the public internet is directly at risk. VCO management interfaces are not designed for internet exposure; they are intended for access from trusted operator networks or through VPN. Misconfigured deployments and remote-access scenarios expand the attack surface.
Cloud-connected hybrid deployments: Organisations running on-premises VCO alongside cloud-hosted resources may have connectivity between the VCO host and cloud management networks, increasing the blast radius of a compromise.
SASE and cloud-only VCO customers: Not affected — the vulnerability is specific to on-premises VeloCloud Orchestrator.
Remediation
Patch immediately. Upgrade VeloCloud Orchestrator to versions 5.2.3.14, 6.1.3.4, 6.4.2.4, or 7.0.0.1 or later for your installed branch. The upgrade process for VCO follows Arista’s standard release update procedure; consult Arista’s customer portal for access to fixed releases.
Network-level containment (parallel to patching):
-
Restrict management interface access: VCO management should be accessible only from dedicated administrator workstations or management VLANs. If the VCO portal is reachable from the internet, immediately add IP allowlisting or place it behind a VPN before completing the upgrade.
-
Identify internet exposure: Use Shodan or Censys to verify whether your VCO instance appears in public scans. VeloCloud Orchestrator uses default ports 80, 443, and 8443 for management access. Any external-facing exposure should be treated as potentially compromised.
-
WAF rules (interim only): Blocking HTTP requests containing shell metacharacters (
; | && $()) in API parameter fields provides limited protection while the upgrade is prepared. This is not a complete mitigation; exploitation techniques that avoid obvious metacharacters may bypass WAF rules.
Post-patch verification: After applying the patch, confirm the VCO software version in the orchestrator UI and verify that no unexpected user accounts, web shells, or configuration changes exist on the VCO host.
Indicators of Compromise
Post-exploitation activity on a compromised VCO host typically includes:
- New files in the web application directory tree (web shell deployment)
- New cron jobs or scheduled tasks added to the VCO host
- Unexpected outbound connections from the VCO server to external IP addresses
- New or modified administrative accounts in the VCO user database
- Configuration push events to Edge devices that are not associated with authorised change requests
- VCO API authentication log entries from unexpected source IP addresses
Log sources to review:
# VCO access log - check for anomalous API paths
grep -E 'POST|GET' /var/log/vco/gateway.log | grep -v "known_admin_IPs"
# System-level indicators
last -F # Recent login history
crontab -l # Scheduled tasks (check for new entries)
find /var/www/ -name "*.php" -newer /var/log/vco/install.log # Recently added web files
netstat -tlnp # Listening services (unexpected ports)Network-level hunt in SIEM:
// KQL — Outbound connections from VCO host to unknown external IPs
DeviceNetworkEvents
| where DeviceName has "vco" or DeviceId in (vco_host_device_ids)
| where RemoteIPType == "Public"
| where RemoteIP !in (known_management_ips)
| summarize ConnectionCount = count(), Ports = make_set(RemotePort)
by RemoteIP, InitiatingProcessFileName
| sort by ConnectionCount desc