VeloCloud Orchestrator under attack: CVE-2026-16812 is an unauthenticated 10.0 RCE

Arista's VeloCloud Orchestrator (VCO) is the brain of a VeloCloud SD-WAN estate -- the single console that provisions and controls every branch tunnel and Edge device. CVE-2026-16812 lets a remote attacker with no credentials reach an internal-only function on the on-prem orchestrator and run operating-system commands on the host that runs it. There is no clever chaining required and no user interaction: network access to the web interface is the only prerequisite (Arista, BleepingComputer).

Scores as of 29 Jul 2026

What the flaw is

At its core the bug is CWE-78 OS command injection: attacker-controlled input reaches a shell on the VCO host without being neutralised. What makes it a clean 10.0 is how that shell is reached. Arista describes functionality that "was intended to be for internal use only and is not intended to be remotely accessible" -- yet an unauthenticated request to the orchestrator's web interface can reach it, and it passes input into a command-execution path (Arista, NVD). Because the injection runs on the underlying operating system rather than staying inside the web app, CVSS scores it Scope: Changed, and the result is full confidentiality, integrity and availability impact on the orchestrator.

The exploitation chain

Publicly, the chain is short and mechanical: reach the internet-facing VCO web interface, cross into the internal-only privileged function, inject an OS command, and land code execution on the orchestrator host -- from which the whole SD-WAN fabric, its databases, certificates and keys are in reach. The two chokepoints a defender actually controls are marked in the diagram: patch/isolate kills the entry, and behavioural detection catches the crossing and the shell.

Am I affected?

Only VeloCloud Orchestrator On-Prem is affected. Arista patched its Hosted and Dedicated cloud orchestrators ahead of the advisory, and VeloCloud Gateway and Edge devices are not directly affected by the bug (Arista, BleepingComputer). If you self-host the orchestrator, check your build against the grid below -- read the running version from the Orchestrator UI or operator console, not from an assumed API path.

Timeline

Exploited in the wild -- but no public exploit yet

Two authorities assert active exploitation -- Arista's advisory and CISA's KEV listing -- but there is no independent researcher confirmation, no named actor or victim, and no disclosed attack-start date; reporting traces back to those two sources plus the three attacker IPs (SecurityWeek, The Register). At the same time there is no public proof-of-concept, no Metasploit module and no Nuclei template -- we verified the Nuclei status directly against the ProjectDiscovery repository. That combination is exactly why the flaw deserves an emergency change now.

How to detect it

With no exploit signature to match, detection is behavioural. First confirm exposure: inventory hosts serving the Orchestrator login portal, read the build, and decide whether the web interface answers from the internet or a general user VLAN -- if it does, treat it as exploitable now. Then hunt for the crossing and the shell.

• Block and hunt the published attacker IPs -- 8.19.75.217, 206.72.242.124, 206.72.242.162 -- both as inbound sources in the VCO web/nginx logs and as outbound destinations from the host. Absence does not clear you; it's one campaign's infrastructure.
• Flag external hits to internal-only functionality. Baseline your admin CIDRs and alert on any VCO web request whose source is outside that allowlist -- an internal-only function should never be reached from the internet.
• Watch the web/app service account for shells. The strongest host signal is the account running nginx/the portal spawning sh/bash/curl/wget/nc/python or recon tools -- the footprint of web-tier command injection.
• Review backend logs for command execution, database exports, new files in web-writable directories (webshells), and reads of certificate/credential/key material.

# Candidate Sigma -- VCO web/app account spawns a shell or network tool (CVE-2026-16812)
# Behavioural (no public exploit signature exists). Tune ParentImage/User to your build.
title: VCO On-Prem Web Account Spawns Shell or Network Tool
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  parent_web_tier:
    ParentImage|endswith: ['/nginx','/node','/nodejs','/httpd','/apache2','/java']
  suspicious_child:
    Image|endswith: ['/sh','/bash','/dash','/curl','/wget','/nc','/ncat','/python','/python3','/perl','/whoami','/id']
  condition: parent_web_tier and suspicious_child
level: high
tags: [attack.t1190, attack.t1059]

How to fix it

1. Patch to the fixed build on your train -- 5.2.3.14 / 6.1.3.4 / 6.4.2.4 / 7.0.0.1 or later. This is the only true fix.
2. If you can't patch this hour, restrict the VCO web interface to trusted admin networks and block the three attacker IPs. This reduces reach; it is not a substitute for patching.
3. If the orchestrator was internet-exposed while unpatched, assume compromise. Patching closes the door; it doesn't evict an attacker already inside. Preserve logs first, then hunt using the signals above.
4. Rotate everything the host could read -- VCO credentials, admin/operator passwords, API keys, certificates and tunnel/orchestration keys -- and validate your managed Edge devices for unauthorised changes. For a confirmed compromise, rebuild rather than trust the patched host.

FAQ

Sources

• Arista -- Security Advisory 0144 (CVE-2026-16812)
• NVD -- CVE-2026-16812
• CISA -- Known Exploited Vulnerabilities Catalog
• BleepingComputer -- Arista patches VeloCloud Orchestrator zero-day exploited in attacks
• SecurityWeek -- Critical Arista VeloCloud Orchestrator vulnerability exploited as zero-day
• The Hacker News -- Attackers exploit Arista VeloCloud
• The Register -- Arista patches actively exploited VeloCloud bug as CISA puts admins on the clock