Arista VeloCloud Orchestrator CVE-2026-16812: Exploited 10.0 RCE on SD-WAN

CVE-2026-16812 (CVSS 10.0) affects VeloCloud Orchestrator (VCO) on-premises — the SD-WAN orchestration console formerly sold by VMware, now part of the Arista portfolio following acquisition. Internal functionality, never meant to be network-reachable, is remotely accessible and allows OS command injection on the VCO host.

The heaviest line in the advisory is the vendor's own:

This issue was discovered externally and is known to be actively exploited.

Added to the CISA KEV catalog on July 27, 2026, with a three-day remediation deadline.

Technical Details

The bug

The Arista advisory describes privileged functionality exposed by mistake:

VeloCloud Orchestrator (VCO) on-prem has a security issue where this issue may allow a remote attacker to access privileged internal functionality and impact the VCO host. Successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator.

This functionality was intended to be for internal use only and is not intended to be remotely accessible.

The CISA catalog specifies the nature: OS command injection. In other words, an internal endpoint — likely intended for inter-component VCO communication or maintenance operations — accepts remote requests and passes parameters to a system call.

This is an architectural flaw more than a coding one: trusted functionality exposed across an untrusted boundary. The vector follows mechanically — no authentication, low complexity, and a changed scope (S:C) because compromise reaches far past the VCO process.

Why 10.0 is warranted here

The maximum score isn't a scoring artefact. A compromised VCO is the control plane for your entire WAN:

• It pushes configuration to every edge (branch, factory, subsidiary appliances)
• It defines the routing, QoS and security policies applied to inter-site traffic
• It holds edge pairing credentials and certificates
• It has full visibility into the organisation's traffic flows

Affected Products and Versions

These are the boundaries exposed by NVD and look like the per-branch fixed releases. Consult the official Arista advisory to identify the exact version to install for your branch.

What is not affected

Hosted and Dedicated versions of VCO have already been patched in advance of this notice going out.

If your VCO is Arista-hosted (Hosted or Dedicated), the vendor patched ahead of disclosure: there's nothing for you to do. The risk sits exclusively with on-premises deployments you operate yourself.

Worth verifying before you convene a crisis call: many organisations don't immediately know which mode their VCO runs in.

Exploitation and Impact

What an attacker gains

Command execution on the VCO host opens several paths, in ascending order of severity:

1. Full WAN reconnaissance — inventory of every site, addressing plans, topology, flow volumes. A map that even an internal audit takes weeks to produce.
2. Theft of pairing secrets — the certificates and keys authorising an edge to join the overlay. With them, an attacker can introduce their own rogue edge into the corporate network.
3. Policy tampering — reroute a site's traffic through infrastructure they control (hence intercept it), disable overlay encryption, or open flows normally forbidden between segments.
4. WAN-wide denial of service — pushing an invalid configuration to all edges simultaneously severs inter-site connectivity for the entire organisation. For a manufacturer or a branch network, the impact is immediate and billable by the hour.
5. Pivot — the VCO sits on the management network, usually the best-connected and least-filtered segment.

The tipping point: "actively exploited"

The vendor's wording leaves no room for doubt. Combined with CISA's three-day deadline, it means exposed VCO instances are currently being scanned and compromised. There is no comfortable observation window here.

Detection and IOCs

VCO logs

Hunt for traces of internal-endpoint access from external sources:

• HTTP requests to paths undocumented in the public VCO API
• 200 responses on endpoints that should only see inter-component traffic
• Requests containing shell metacharacters (;, |, `, $() in parameters

On the VCO host

# Unexpected child processes of the VCO service
ps -ef --forest | grep -A5 -i velocloud

# Recent files in temp directories
find /tmp /var/tmp /dev/shm -type f -mtime -45 -ls 2>/dev/null

# Persistence
crontab -l
ls -la /etc/cron.d/
systemctl list-unit-files --state=enabled | grep -vE "^(sshd|network|velocloud)"

Network traffic

The most reliable signal: the VCO has a highly predictable communication profile (edges, IdP, update repositories). Any outbound connection to a destination outside that list warrants investigation.

Configuration integrity

Compare the configuration pushed to edges against your last known-good backup. A policy change not tied to a documented request is a major indicator of compromise — and it's precisely the action an attacker is after.

Mitigation and Patch

1. Identify your deployment mode

First things first: Hosted/Dedicated (nothing to do) or on-prem (urgent action)?

2. Patch — urgently

Pull the fixed release for your branch from the Arista support portal and apply it. Given active exploitation and a CISA deadline of July 30, this is not a monthly-maintenance item.

3. Isolate the admin interface immediately

This is the most effective short-term mitigation, applicable even before patching. The VCO must not be reachable from the internet or from user VLANs:

# iptables example — restrict admin to management IPs
iptables -A INPUT -p tcp --dport 443 -s <management-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Be careful to preserve reachability from the edges, which must keep talking to the orchestrator — filter on known source IPs rather than cutting everything.

4. After patching: treat compromise as a live hypothesis

If your on-prem VCO was exposed, the patch doesn't close the matter:

1. Rotate VCO administration credentials
2. Regenerate edge pairing certificates and secrets if your architecture allows it
3. Verify the integrity of the configuration pushed to each edge against a known-good reference
4. Audit the list of registered edges — an unknown edge is permanent network access
5. Hunt for host persistence (cron, systemd, modified binaries)

5. Long-term hardening

• VCO on a strict management VLAN, reachable only through a bastion
• Logs exported to an external SIEM in real time — a root-level attacker will wipe local logs
• Regular offline backups of the configuration, so you can detect drift and restore

Why Continuous Monitoring of Control Planes Matters

There's a category of equipment whose compromise doesn't affect one service but the whole infrastructure: SD-WAN orchestrators, Wi-Fi controllers, hypervisors, firewall consoles, certificate managers. These systems share three traits: few in number (so forgotten by inventories), agentless (so invisible to classic scans), and operated by a small specialist team that doesn't necessarily track advisories daily.

That's exactly the profile in which an actively exploited 10.0 CVE can sit unpatched for weeks.

With cveo.tech, inventory your network control planes alongside your servers and get automatic alerts whenever a critical CVE targets one of your exact versions — with CISA KEV status surfaced up front, so you immediately tell the theoretical apart from the already-exploited.