CVE-2026-16812

What is VeloCloud Orchestrator?

VeloCloud Orchestrator (VCO) is the centralized management and control plane for VeloCloud SD-WAN — the product line that began at VMware, moved to Broadcom, and is now owned by Arista Networks. VCO is where administrators define the entire SD-WAN overlay: business policy, application steering rules, VPN topology, Edge device onboarding and activation, firmware distribution, and per-tenant configuration for every VeloCloud Edge appliance in the fleet. It is explicitly multi-tenant — service providers and large enterprises run a single VCO managing hundreds or thousands of branch Edges.

The product ships in three deployment models: VCO Hosted (Arista-run SaaS), VCO Dedicated (Arista-run single-tenant), and VCO On-Prem (customer-operated). Only On-Prem is affected by this vulnerability; Arista patched the Hosted and Dedicated environments before the advisory went public. VeloCloud Gateway and VeloCloud Edge are not affected.

Compromising the orchestrator means owning the WAN. An attacker with code execution on VCO can read every managed site's configuration, extract Edge activation keys, credentials and certificates, push malicious configuration or firmware to branch devices, and reroute or mirror traffic across the entire SD-WAN fabric. The exposure problem is structural: the orchestrator has to be reachable by remote Edges to do its job. As SecurityWeek noted in its coverage, VCO's management interface "is exposed by default. There is no configuration that can prevent the exposure."

Overview

Arista VeloCloud Orchestrator On-Prem contains an OS command injection vulnerability that allows a remote, unauthenticated attacker to reach privileged internal functionality and execute commands on the VCO host. Successful exploitation compromises the confidentiality, integrity, and availability of the orchestrator and of the data it manages.

The vulnerability carries a CVSS base score of 10.0 — the maximum. It requires no authentication, no user interaction, and no special conditions, and its impact crosses a security boundary out of the web application and into the underlying host.

Arista disclosed the flaw and shipped fixed builds on 2026-07-27, stating in the same advisory that the issue "was discovered externally and is known to be actively exploited." This was a zero-day: there was no patch window. CISA added it to the KEV catalog the same day with a three-day remediation deadline.

Affected Versions

Technical Details

CWE-78 — Improper Neutralization of Special Elements used in an OS Command. The root cause is two-part. Arista's advisory states that the affected functionality was "intended exclusively for internal use and should not have been remotely accessible" — so a privileged internal code path was reachable from the network-facing web interface, and input arriving on that path reached an OS command without adequate sanitization. Either defect alone would be serious; together they produce unauthenticated remote code execution.

Attack characteristics:

• Authentication: none. No credentials and no tenant authorization are required. Network access to the VCO web interface is sufficient.
• Complexity: low. No race conditions, no information the attacker must first obtain, no user interaction. A single unauthenticated HTTP request is enough to reach command execution.
• Single request, not a chain. This is a standalone pre-auth RCE — no companion CVE is needed to reach it. Rescana's write-up describes observed activity as scanning for publicly reachable orchestrator endpoints, delivering payloads via HTTP POST or GET, and then using the resulting command execution to establish persistence.
• Scope: Changed (S:C). This is why the score is 10.0 rather than 9.8. The vulnerable component is the web application, but the impact lands on the underlying VCO host OS and, transitively, on the managed tenant and Edge estate. CVSS 4.0 expresses the same idea as subsequent-system impact (SC:H/SI:H/SA:H).

Arista has not published the vulnerable endpoint path, the parameter name, or the internal service being invoked, and no public technical write-up or proof-of-concept has surfaced. The absence of exploit detail slows commodity exploitation somewhat, but it does not help defenders identify attempts — which is why the log-hunting guidance below matters.

Discovery

Arista states only that the issue "was discovered externally and is known to be actively exploited." No researcher, vendor, or organization is credited in the advisory, and no attribution appears in the coverage from BleepingComputer, SecurityWeek, The Register, or The Hacker News. Discovery credit is unpublished.

Exploitation Context

Confirmed exploited in the wild as a zero-day. Arista's advisory says so directly; the fix and the advisory were published simultaneously on 2026-07-27, and CISA added the CVE to KEV the same day.

Arista published three attacker source IP addresses, noting the list is "not definitive":

8.19.75.217
206.72.242.124
206.72.242.162

No threat actor, ransomware group, or campaign has been named, and Arista has not disclosed when attacks began or how many customers were affected. No Shodan, Censys, or Shadowserver exposure counts have been published for internet-facing VCO On-Prem instances.

On the three-day deadline. The unusually short window — KEV addition 2026-07-27, deadline 2026-07-30 — is not an emergency directive. CISA now operates under BOD 26-04, "Prioritizing Security Updates Based on Risk," which replaced BOD 22-01's flat KEV timelines with risk-tiered deadlines scored against four criteria: asset exposure, KEV status, exploit automation, and post-exploitation technical impact. The most aggressive tier — KEV-listed, publicly exposed, automatable, and granting total control — carries a three-day deadline plus a forensic triage requirement. CVE-2026-16812 satisfies all four. Note the triage element: agencies are directed to assess for prior compromise, not merely to patch.

A note on conflicting reporting: The Hacker News printed an August 10 deadline for this CVE, which appears to be a mix-up with the concurrently-listed FortiOS issue (CVE-2025-68686), and BleepingComputer referenced the superseded BOD 22-01. The CISA KEV catalog date of 2026-07-30 under BOD 26-04 is authoritative.

Remediation

1. Patch immediately to VCO On-Prem 5.2.3.14, 6.1.3.4, 6.4.2.4, or 7.0.0.1, matching your release train. There is no vendor workaround that removes the vulnerability.
2. Restrict the VCO web interface to trusted administrative networks or VPN-only access. This is Arista's primary interim mitigation, but understand its limit — Edges must reach the orchestrator, so this constrains exposure rather than eliminating it.
3. Block and hunt the published attacker IPs — 8.19.75.217, 206.72.242.124, 206.72.242.162 — in perimeter logs and VCO access logs. Treat the list as a starting point, not a complete set.
4. Review logs for exploitation evidence. Arista directs examination of VCO web access logs, backend application and system logs, database logs, and filesystem timestamps. Look specifically for requests with unusual URL paths, encoded characters, or references to internal services; unexpected command execution; database exports; unexpected file creation; and access to stored credentials or certificates.
5. Check for unexpected outbound network activity from the VCO host. An orchestrator initiating egress to the internet is abnormal and is a strong indicator of post-exploitation activity.
6. Audit administrator activity for unauthorized configuration changes across all tenants.
7. If compromise is suspected, preserve web access, application, system, and database logs along with filesystem timestamps before remediating. Then rotate credentials on VeloCloud Edge devices, validate the configuration state of every managed device, and rebuild or restore orchestrator instances from a trusted source rather than attempting to clean in place. Given that the attacker had root-equivalent access to the SD-WAN control plane, in-place cleanup cannot establish trust.