CVE-2026-16812: Arista VeloCloud Orchestrator Unauthenticated Command Injection (CVSS 10.0) — How to Find Exposed Instances

An unauthenticated attacker can reach privileged internal functionality on Arista's VeloCloud Orchestrator and execute OS commands on the host. Arista rates it CVSS 10.0 on both v3.1 and v4.0, says it was "discovered externally and is known to be actively exploited," and CISA added it to the Known Exploited Vulnerabilities catalog on July 27, 2026 with a three-day federal deadline that has already passed. The orchestrator is the control plane for an entire SD-WAN fabric — and Arista notes that compromising it may hand attackers the Edge devices too. Here's how to find VeloCloud Orchestrator instances on your network and what to check if you find one.

The Vulnerability

CVE-2026-16812 (CWE-78: OS Command Injection) lets a remote attacker reach privileged internal functionality in VeloCloud Orchestrator (VCO) and impact the VCO host. Arista's advisory states that successful exploitation "may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator." No authentication is required.

"Intended for Internal Use Only"

The mechanism is in one sentence of Arista's advisory: "This functionality was intended to be for internal use only and is not intended to be remotely accessible." The vulnerable functionality was privileged by design. The control that was supposed to keep it out of an attacker's reach was not a permission check or a sandbox — it was an assumption about who could route a packet to it.

That assumption is the same one this blog keeps finding at the centre of critical vulnerabilities. Langflow treated an authentication check as containment for an exec() endpoint. Cisco's SD-WAN Manager treated a login as containment for a file-upload path that reached root. Here, Arista treated network topology as containment for a privileged internal interface. In each case the execution capability was always there; only the routing to it was ever in question. When intent is the only thing standing between a network caller and privileged functionality, "internal" is a naming convention, not a boundary.

Why the Orchestrator Is the Target

VeloCloud Orchestrator is the management and policy plane for a VeloCloud SD-WAN deployment: it configures, monitors, and pushes policy to every VeloCloud Edge appliance in the fabric. That makes it a high-value single point of compromise rather than one host among many. Arista makes the blast radius explicit: "Compromises to the VCO platform may allow attackers access to the VeloCloud Edge devices as well." An intruder on the orchestrator is positioned to alter routing, change security policy, and reach the branch sites the fabric terminates.

Two Details Worth Getting Right

Hosted is affected too. Arista's advisory shipped as revision 1.0 on July 27 saying Hosted and Dedicated versions "have already been patched in advance of this notice going out." Revision 1.1, published August 3, changed that to "are being actively patched" and added VeloCloud Orchestrator Hosted to the affected platforms list. Reporting that repeats the original wording — or the NVD record, which still carries the July 27 text — will tell readers that cloud-hosted deployments were never exposed. Read the live advisory. The CISA KEV entry is still titled "Arista VeloCloud Orchestrator On-Prem," which understates the current scope for the same reason.

The product changed hands. VeloCloud was VMware's, then Broadcom's, and is now Arista's — the advisory is published by Arista's PSIRT and the NVD record is assigned by [email protected]. Asset inventories, vulnerability scanners, and internal documentation that still say "VMware VeloCloud" or "VeloCloud by Broadcom" describe the same product. If you search your CMDB for the wrong vendor string, you will conclude you do not run it.

Investigation Workflow

VCO is a management-plane system, so it is often deployed in an administrative network rather than on the public internet. "Often" is doing real work in that sentence — the advisory's first mitigation is to restrict access to the web interface to trusted administrative networks, which is only advice worth giving because deployments frequently do not. The goal here is to enumerate every orchestrator you run and establish where each one is actually reachable from, rather than where the architecture diagram says it sits.

1. Port Scan: Find Orchestrator Instances

VCO presents a web management interface. Scan management and data-centre subnets for:

• • 443 — primary HTTPS management and API interface
• • 80 — HTTP, typically redirecting to 443; useful as a fingerprint even when it only redirects
• • 22 — SSH to the orchestrator host

Scan from more than one vantage point. An orchestrator that answers on 443 from a general-purpose user VLAN is a materially different finding from one that answers only from a jump host, and a scan run entirely inside the management network cannot tell the two apart.

2. TLS Inspect: Identify VeloCloud Certificates

Pull the certificate on port 443 and read the subject, issuer, and SAN entries. Look for velocloud, vco, sdwan, or the operator's own orchestrator hostname. Because the product has moved between three vendors, certificates issued at different points in a deployment's life may carry VMware, Broadcom, or Arista organization strings — treat any of them as a hit rather than filtering on the current vendor name.

3. HTTP: Fingerprint the Management Interface

Request the root path and inspect the response. VCO serves its administrative UI over HTTPS on 443, with documented login paths including /operator and, on some releases, /ui/operator. The API namespaces are the more durable fingerprint: /portal/ is the API v1 JSON-RPC endpoint, /portal/rest/ the API v1 REST base path, and /api/sdwan/v2 (formerly /sdwan) the API v2 base. Note that /portal/ is an API namespace rather than the browser UI prefix — a distinction worth getting right before writing it into a detection rule. Record the reported build string where the interface exposes one; you need the exact release to compare against four separate affected trains.

Confine this to unauthenticated fingerprinting of systems you are authorised to test. The vulnerable functionality is reachable without credentials, which makes it easy to cross from confirming a version into interacting with the flaw itself. Version confirmation belongs in the change record; exploitation belongs in a scoped engagement with written authorisation.

4. DNS: Discover Orchestrator Infrastructure

Query internal DNS for the naming patterns operators give SD-WAN management hosts: vco.*, velocloud.*, orchestrator.*, sdwan.*, wan-mgr.*. VeloCloud deployments also include Gateways and Edges, so hosts named vcg-* or edge-* in the same zone indicate a fabric whose orchestrator is somewhere nearby.

5. CVE Lookup: Confirm Scope and Status

Pull CVE-2026-16812 and compare the affected trains against your inventory. Note that the NVD record was published July 27 and carries the original advisory text, so treat Arista's page as authoritative for platform scope and the KEV catalog as authoritative for exploitation status and deadlines.

Cross-Reference with External Data

Indicators of Compromise

Arista's advisory publishes three source addresses observed in exploitation attempts. Search perimeter, proxy, and orchestrator logs for traffic from:

• • 8.19.75.217
• • 206.72.242.124
• • 206.72.242.162

Treat these as confirmation, not as a clean bill of health — a negative result rules out three addresses, not exploitation. Arista also directs operators to look for unexpected URL-like path components, encoded characters and references to local or internal services in request logs; unexpected outbound HTTP or HTTPS activity from VCO hosts; unaccounted configuration changes; unauthorised command execution; and anomalous database access.

Remediation

1. Upgrade to the fixed release for your train. 5.2.3.14, 6.1.3.4, 6.4.2.4, or 7.0.0.1 and later. The KEV deadline was July 30, 2026 — for an internet-reachable orchestrator this is overdue remediation, not scheduled maintenance.
2. Confirm your deployment type with Arista. Revision 1.1 lists both On-Prem and Hosted as affected and describes Hosted and Dedicated versions as "being actively patched." If you run Hosted or Dedicated, ask Arista to confirm in writing that your specific instance is patched, and record the date — do not infer it from the advisory.
3. Restrict access to the management interface. Arista's own first mitigation: limit the VCO web interface to trusted administrative networks. Verify this by scanning from a user subnet, not by reading the firewall rules.
4. Treat a pre-patch exposed orchestrator as a potential incident. Exploitation is confirmed and the flaw needs no credentials. Preserve logs before they roll, then review administrator actions, configuration changes, and database access across the window in which the instance was reachable.
5. Rotate credentials and keys the orchestrator holds. A control plane stores the material it uses to manage everything downstream. Patching closes the entry point; it does not invalidate anything an intruder already copied.
6. Validate the fabric, not just the host. Arista states that a VCO compromise may extend to VeloCloud Edge devices. Compare running Edge configuration and policy against your intended baseline rather than assuming the blast radius stopped at the orchestrator.

Triage Notes

Sources

• → Arista Security Advisory 0144 (CVE-2026-16812)
• → NVD: CVE-2026-16812
• → CISA Known Exploited Vulnerabilities Catalog (CVE-2026-16812 added July 27, 2026)
• → NVD: CVE-2026-20262 (Cisco Catalyst SD-WAN Manager)