Arista's VeloCloud Orchestrator Exposes an Internal Command Path to the Whole Internet: CVE-2026-16812 Ships CVSS 10 Unauth RCE

Somewhere in a branch office right now, a router is calling home to a VeloCloud Orchestrator that has been sitting on the public internet since the day it was racked. That is not a config mistake; it is the product's default posture, which Arista's own advisory acknowledges when it notes that the on-prem VCO's web interface has to remain reachable from the sites it manages and cannot be firewalled to a purely internal segment without breaking the fabric. What we at BlueTeamAutomation cannot stop turning over about CVE-2026-16812 is that the flaw shipping through that exposure is not a subtle deserialization gadget or a memory bug you need a lab to reproduce. It is an unauthenticated OS command injection, CVSS 10.0, and CISA added it to the Known Exploited Vulnerabilities catalog on July 27, 2026 with a three-day federal patching deadline that lands on July 30.

The thing that keeps snagging us is where the bug lives. Command injection in an internet-facing appliance is nothing new. This one, though, sits in a central management plane that already holds the credentials, tunnel keys, and running configurations for every SD-WAN edge downstream of it. One unauthenticated request to the wrong route and the attacker is not on one branch router. They are inside the fabric that operates every router the enterprise owns, which is why the CVSS scored the scope as changed and why The Hacker News reported observed exploitation before Arista shipped a patch.

A management plane that answers strangers by design

The affected component is the on-prem VeloCloud Orchestrator, the central management platform for VeloCloud SD-WAN infrastructure that Arista now ships as its VCO product line. Its job is to program every edge appliance, define application-aware routing policies, distribute IKE keys and IPsec parameters, and hold the golden copy of every branch's config. Because branch routers reach out to the orchestrator rather than the other way around, the VCO's web management interface has to answer HTTP from anywhere its edges live, which in enterprise deployments means anywhere on the internet. Arista's own guidance in Security Advisory 0144 is that the on-prem VCO cannot be fully removed from that exposure through configuration alone; a network-layer allowlist is the only real answer. VeloCloud Orchestrator Hosted and Dedicated cloud offerings were silently patched before public disclosure and are not affected.

The internal function that leaked to the outside

The technical wording Arista and CISA have released describes CVE-2026-16812 as an OS command injection flaw (CWE-78) reached through the VCO web interface, in which "privileged internal functionality intended only for internal use" is exposed to unauthenticated network callers. Read that carefully. The bug is not a missing sanitizer on a normal user-facing feature; it is an internal function that shells out to the OS, wired into a request route that was never supposed to be network-reachable, and reachable now with no credentials and no user interaction at all. Arista has withheld the specific endpoint path and payload shape while active exploitation continues, which is the responsible move, and no public PoC has yet named the route. What is public and useful is the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), which says the request is one call over the network at low complexity, and the fact that the shell it lands in runs with the orchestrator's own privileged identity, per SecurityWeek's coverage of the advisory.

What we can say plainly is the shape of the class. An internal maintenance or diagnostic function that shells out to the OS is safe only if the caller is genuinely internal. The moment a routing bug, a forgotten proxy pass, or a URL rewrite hands that function a request from anywhere else, the shell metacharacters in the caller-controlled parameter get evaluated by whatever system()-shaped primitive the function uses under the hood, and the sanitizer built for trusted internal callers was never asked to defend against an anonymous stranger.

The observation floor around an SD-WAN orchestrator

The reason this class of bug is so ugly on a VCO in particular is what defenders can actually see. The management network your orchestrator lives on tends to be one of two things: a customer-only VLAN that your NDR does not sniff, or the raw internet, which your NDR sees but writes off as "expected orchestrator traffic." Almost nobody baselines POST bodies to the VCO web interface, because every branch router POSTs there constantly and the API is proprietary. A WAF, if it is even in front of the VCO (usually not, since the vendor ships a self-managed appliance), has no ruleset tuned for a private orchestrator API. The application-layer signal that would say "someone injected a shell metacharacter into a management route" gets absorbed by the noise of legitimate SD-WAN telemetry, and by the time the orchestrator's request handler has processed the injected command it has already run under the service account.

What one unauth request buys the attacker

Code running on the VCO host under the orchestrator's identity hands over the trust root of the SD-WAN fabric in a single shot. The attacker can read every edge's running configuration, extract the IKE preshared keys and IPsec certificates used to bring up branch tunnels, pull the RADIUS or TACACS credentials the orchestrator holds to push configs, and rewrite policies to route branch traffic through infrastructure they control. In an SD-WAN, the orchestrator is the source of authority for the entire fabric, so an edge that receives a new config or policy from it will apply that config, because that is the operating model. That is exactly what the S:C flag in the CVSS vector captures, and it is why the vulnerability scored a full 10.0 rather than a bare unauth RCE at 9.something. The blast reaches transitively into every managed device downstream.

Hunts to run against the VCO host and the perimeter

Without a public payload signature yet, defenders have to work from behavior on the box. On the VCO host, treat any unexpected child process of the orchestrator's web tier as a strong signal. In practice that means alerting on any spawn of bash, sh, dash, python, perl, curl, wget, nc, or openssl under the VCO's Node.js or nginx worker parent; the orchestrator's normal request loop does not fork shells. Any file write outside the VCO's expected data directories, especially into /tmp, /var/tmp, /dev/shm, or user home directories, is worth capturing. A second useful signal is an outbound connection from the VCO host to an address that is not one of your managed edges, your syslog target, or a known SaaS integration; edge tunnels are IPsec, not arbitrary HTTP callouts, so a Node process reaching out to a fresh IP over TCP is almost always wrong. Correlate any hit from those against an HTTP entry in the VCO access log whose URI parameters or body carry shell metacharacters (;, |, &&, $(, backticks, or URL-encoded %0a).

At the perimeter, restrict the VCO web interface to a management IP allowlist even now that the patch is out; the CISA KEV entry mandates it as the interim mitigation and Arista recommends the same. Suricata or Zeek watching the management VLAN can score every VCO POST that carries the shell-metacharacter set above, since false positives on a private management API are rare. In MITRE ATT&CK terms the chain reads as T1190 Exploit Public-Facing Application into T1059.004 Command and Scripting Interpreter, escalating into T1210 Exploitation of Remote Services against every edge whose config now flows through a compromised orchestrator.

Patch, rotate, and prove the fix actually took

Apply the fixed releases immediately: VCO 5.2.3.14, 6.1.3.4, 6.4.2.4, or 7.0.0.1, depending on which train your appliance is on. If a patch window is not immediately possible, gate the VCO web interface to a management IP range at the network layer, which closes the reachable surface even though the interface itself remains exposed by product design. Assume prior compromise for any on-prem VCO that has been internet-reachable in the last two weeks; Arista's advisory confirms zero-day exploitation before the patch and the CISA KEV addition on July 27 confirms government observations of that exploitation in the wild. Rotate anything the orchestrator held that could still be valid, including IKE and IPsec keying material, VCO admin credentials, API keys to RADIUS, TACACS, syslog, and any SSO IdP, and reset every managed edge's shared secret rather than trusting the current one.

Do not accept the "patch installed" status page as proof the fix took. Two things go wrong with orchestrator upgrades in the wild that should keep any SOC honest. Minor releases sometimes preserve a stub of the vulnerable route for backward compatibility, and multi-node HA VCO deployments occasionally roll one node while another node's HTTP tier still serves the vulnerable build. The trustworthy proof is a repeatable synthetic probe against the fixed endpoint (once Arista publishes it), which should come back with the expected refusal signature every time; re-run that probe after every upgrade window and every failover event. Cross-reference the result with the process-tree hunts above, because a good run should look like nothing happened on the host at all.

The BTA line

Patch on Monday, drift on Wednesday, re-exploited on Thursday is the loop that eats SD-WAN fabrics, and closing it is the exact motion BlueTeamAutomation automates end to end, with BASzy replaying primitives like this VCO probe on a schedule so your detection stays honest and your mitigation stays proven after every release train and every HA failover.